Why we started vibePulse
Coding got faster. Knowing that a shipped app was still alive did not. vibePulse started as a small product for that gap—not as a full observability suite, and not as a pitch deck feature list.
A scene we kept seeing
A pattern showed up often enough that it stopped feeling like anecdote. Someone builds with an AI coding agent overnight. The landing page responds. The API answers a few test calls. A webhook fires once. Then the next morning—or three days later—someone asks why a bot went silent, why a cron never ran, or why a demo link suddenly returns an error page. The builder reboots a VPS, scrolls container logs, rotates a key that expired without warning, and discovers there was never a health check. The product was “done.” Ops was an afterthought. That is not a moral failure. Tooling made the build loop cheap. The loop for “is this thing still alive for users who are not me?” stayed expensive: APM suites, agent installs, dashboards meant for teams that already have an SRE habit. Solo builders and tiny teams fall into a hole between “I can ship” and “I will notice when it dies quietly.” We kept hitting the same hole in our own work and in conversations with people shipping vibe-coded side projects. The failure mode is quiet. No loud deploy error. Just silence until a human notices. The awkward part is how normal this became. People apologize for “not knowing DevOps,” as if noticing downtime required a job title. It does not. It requires a check that runs when you are asleep, and a place that yells when the check fails. Without that, vibe coding’s speed advantage turns into a liability: you can create more soft production surfaces than you can personally babysit.
The question that mattered
We narrowed the product to one question: how do I know my app is alive right now? Not “give me flame graphs.” Not “replace my entire stack.” Alive, soon after something breaks, on a channel I already open—Telegram, Discord, or Slack. That question splits into two checks. Public URLs need probes: HTTP status, latency, and a simple assertion that the page is not an error shell. Background workers and agents often have no useful public URL; they need a heartbeat—something that says “I ran” on a schedule. Missing either side leaves a blind spot. We also cared about time-to-first-monitor. If setup takes an afternoon of YAML and agent installers, the people who most need the check will skip it. The first useful signal had to fit in minutes, with a free path, and with install notes that match how people actually build now—Cursor, Claude Code, Codex—not only a manual dashboard click path. We wrote the question on a sticky note and used it as a filter. If a feature did not help answer “alive right now?” faster or clearer, it waited. That filter killed several tempting ideas early—pretty charts nobody would open, integrations that looked good in a comparison table, and copy that promised “enterprise grade” before we had a reliable free loop.
What we shipped first
vibePulse is that minimum unit. Create an account, add a URL monitor or a heartbeat, connect an alert channel, and get notified when the check fails. The product lives at https://vibepulse.goodtek.xyz. The hub how-to is at /guides/vibepulse. The product sits next to the rest of the ecosystem on /apps. We deliberately did not wait for a complete platform. Completeness is how thin marketing sites get written before anyone has a usable loop. A free first monitor, clear free-tier limits, and a path from “I shipped last night” to “I will hear if it dies” mattered more than a feature matrix. Alert routing is part of the same story. Email-only alerts get buried. Builders already live in chat tools. If the alert cannot land where attention already is, the monitor is theater. Documentation on the hub is part of the product surface. If someone lands on goodtek.xyz first, they should be able to reach a how-to without guessing which subdomain owns the truth. That is why /guides/vibepulse exists beside the app itself.
What we chose not to be
We are not pretending vibePulse replaces Datadog, Sentry, or a full metrics stack. Those tools solve different jobs for different stages. Our bet is earlier and narrower: catch “it stopped” before a week of silence, for people who will not adopt enterprise ops tooling for a weekend ship. That boundary keeps the product honest. It also keeps the docs honest. A getting-started guide that promises world-class observability would be marketing. A guide that walks URL checks, heartbeats, and alert channels is operational. We would rather be useful in a small square than vague across a large one. Narrowness also protects users from false confidence. A green check on one URL is not a full reliability program. We say that in the guide on purpose. The job is to remove the worst blind spot first.
Why this product, under goodtek
goodtek’s public bet is that AI-accelerated building needs matching operational habits—not only prettier landing pages. vibePulse is the first product-shaped expression of that bet: small enough to try, specific enough to judge, and honest about what it is not. If the product helps even a fraction of quiet failures get caught the same day, the bet is working. If it does not, we will say so in public and change the shape. That is the deal we are making with anyone who follows along.
Still missing—and how we will fill it
Alert fatigue is real. One noisy monitor teaches people to mute everything. Team workspaces, richer schedules, more monitors, and better severity controls are on the path. We will ship those in public rather than hide behind a roadmap graphic. If you have lived the quiet-failure scene—AI-shipped app, no checks, surprise downtime—tell us what broke and what you wished existed. Email hello@goodtek.xyz. Product: https://vibepulse.goodtek.xyz. Setup: /guides/vibepulse. Next public steps include making noisy alerts harder to create by accident, and making multi-monitor setups less painful for people who ship more than one weekend project. None of that needs a rebrand. It needs boring, shipped increments.