From Vibe-Coding to Launch: The Four Stages Where Products Die

Most AI side-projects don't die at the idea stage. They die between stages. Specifically, they die between prototype and MVP — the place where you have to stop adding features and start running it like a product. Between summer 2025 and January 2026 I've shipped about a dozen things and watched a lot more fall apart, and the failure mode is consistent: people don't know which stage they're in, so they apply the rules of an earlier stage to a later one. Or skip stages entirely.

This is the funnel I now run every project through. Four stages, three gates between them. Each gate has one specific job.

Stage 1: Vibe-coding

This is where it starts. Open Claude Code or ChatGPT, describe the idea, get something running on localhost in twenty minutes. There's no plan. There's no eval. There's no schema you're committed to. You're checking whether the idea has a pulse.

The work: describe → run → see → describe again. Tight loop. No PR. No tests. No deployment. The output is a localhost URL or a terminal session that does the thing once.

What kills you here: premature seriousness. People reach for project structure, write specs, set up CI — all before they know if the idea works. The vibe-coding stage is the cheapest place to learn that an idea doesn't matter. Spending two days hardening it before you've seen it run is a tax on your future productivity.

The gate to stage 2: you can show a non-technical person what it does and they get it in under thirty seconds. If they don't, you don't have an idea yet. Go back.

Stage 2: Prototype

Prototype means: a real repo, a real eval, a real readme. You're not committed to shipping it. You are committed to being able to ship it. The eval matters most. Without an eval, you have no way to know if a model change made things better or worse, and you'll spend the rest of the project flying blind.

The work: restart from scratch with structure. Pick the model. Pick the deployment shape (cloud / local / hybrid). Write the eval — 10 to 30 examples that capture what "working" means. Get to a state where one command runs the eval and prints a score.

What kills you here: skipping the eval. Without it, every "improvement" is vibes. Three weeks in, you have a thing that feels better than it did at the start, no idea whether that's true, and a model decision you can't justify when a teammate or a client questions it.

The other thing that kills you: scope creep. Prototype is the stage where every passing engineer wants to add a feature. The right answer is no. The eval defines what done looks like. Anything that doesn't move the eval score doesn't go in.

The gate to stage 3: the eval score is acceptable for what you said the product is, you have one paying or near-paying user willing to use the thing, and the deployment story is real (not "I'll figure that out later").

Stage 3: MVP

MVP means: real users, real billing or real signups, real support obligations. You don't get to take a week off. The product is live and someone is depending on it. Most of the engineering work in stage 3 isn't features — it's the boring stuff. Auth. Logging. Rate limits. Email confirmations. A way for users to delete their data. A way for you to see what's happening when something breaks at 11 PM.

The work: harden everything. Pick a hosting story you can sleep on. Add observability. Write the runbook. Decide what "outage" means and how you'll know one is happening.

What kills you here: continuing to vibe-code. Stage 3 is where vibe-coding becomes dangerous. The same Claude Code call that was perfect in stage 1 will gleefully drop a DROP TABLE migration into your prod database if you let it. Stage 3 demands review gates, deterministic eval CI on every PR, and humans in the loop for anything that touches state.

The other thing that kills you: premature scaling. MVP is for learning what users actually do. It's not for handling 10x traffic. It's not for going viral. Most "MVP failures" are actually stage-2 prototypes deployed without ever earning the right to be called an MVP.

The gate to stage 4: you have ten users who'd be visibly upset if it disappeared, the eval score has held steady for two weeks, the runbook has been used at least once, and you have a real answer to "how does this make money."

Stage 4: Launch

Launch is when you tell the world. Not when you ship it — you shipped it weeks ago. Launch is when you take the work you've been doing quietly and put it in front of distribution: write the post, do the demo video, post on Hacker News, line up the LinkedIn thread, email the people who'd care.

The work: distribution. Marketing. The launch surface — a landing page, a demo video, a benchmark or comparison that makes the value legible in thirty seconds. This is where most engineers get uncomfortable, because none of this feels like engineering. Do it anyway. The product is built. The job now is making sure it gets seen.

What kills you here: under-investing. Launch day is one day. The window in which a piece of work has freshness is also short — maybe two weeks. If you ship the build but skimp the launch, you've left the upside on the floor.

There is no gate after this. Launch is the end of the funnel. After launch, you either iterate (back to stage 2 with a new feature, run the funnel again) or you sunset (admit it didn't work, learn the lesson, move on).

What this funnel changed for me

Before I had this framing, I was almost always in stage 1 even when I claimed to be in stage 3. I'd vibe-code an MVP feature directly into a repo with paying users. I'd skip the eval because the prototype "felt right." I'd ship a launch post for a thing that wasn't actually production-ready and then spend the next week firefighting.

The funnel makes the question explicit: which stage am I in right now, and am I applying the right rules? It's almost embarrassing how often the answer is "I'm in stage 1 with stage 3 ambitions" and the fix is to back up.

The other change: agentic engineering accelerates every stage, but stage 1 most of all. Vibe-coding with Claude Code and Codex CLI in parallel collapses the time-to-pulse from "an evening" to "an hour." That sounds like a small win until you realize how many ideas you can now check before committing to one.

If you're working on a thing right now and feeling stuck, ask yourself which stage you're in. Then ask whether you're playing by that stage's rules or somebody else's. Most of the time, the answer surprises you.