From vibe-coded prototype to production: what actually has to change

A founder can now describe a product to an AI coding tool and have something that runs by Sunday evening. This is genuinely new, and the reflex to dismiss it is wrong — the prototype is real, it demonstrates the idea, and it was built for a fraction of what a discovery phase used to cost.

What is not true is that it is nearly finished. We audit a lot of these now, and the gap is consistent enough to write down. None of it is a criticism of the tools; it is the part of software that has never been about typing code.

What vibe coding genuinely gets right

Worth being specific, because the useful parts are usually worth keeping. The screens are often good — layout, flow and copy are exactly the kind of thing these tools do well, and they encode real product thinking from whoever wrote the prompts. The feature set is usually honest, because it was built by someone who understands the customer rather than negotiated across a committee. And it answers the only question that matters at that stage: is this worth building properly?

The five things that are almost always missing

In rough order of how much trouble they cause:

• Authorisation, as distinct from login. Prototypes almost always have sign-in and almost never have rules about who may see which record. This is the one that becomes a data breach rather than a bug, and it is usually the reason a prototype cannot simply be launched.
• The data model. Generated schemas tend to be shaped around the first screen, so fields are duplicated across tables, relationships are implied rather than enforced, and nothing stops contradictory rows. Cheap to fix at fifty rows; a migration project at fifty thousand.
• Secrets and keys. API keys pasted into client-side code or committed to the repository. Anything shipped to a browser is public, and a key in a git history stays there after it is deleted from the file.
• Anything about failure. The happy path works. A payment that half-succeeds, an upload that times out, a webhook delivered twice — these produce silent corruption, because no one wrote the branch.
• Tests and a way to deploy. Usually there is neither, which means every future change is a gamble and every release is a manual ritual performed by whoever is brave.

A prototype proves the idea is worth building. It does not prove the build is nearly done.

The other thing: it is hard to change

The subtler problem is repetition. Generated code often solves the same problem five times in five places, because each prompt was answered on its own. Nothing is technically wrong, and every future change costs five edits and four chances to miss one. This is why velocity on a vibe-coded codebase tends to feel excellent for three weeks and then collapse.

How we audit one

A few days, and the output is a plain document rather than a proposal. What can stay as it is. What needs rework and why, in terms of what would go wrong if it did not. What has to be rebuilt. What each part costs, and what the sensible order is — because the order matters: authorisation and the data model first, cosmetics last, since everything else is built on those two.

Sometimes the honest answer is that the prototype should be thrown away and its screens kept as the specification. We say so when it is true. It is usually cheaper than the alternative, and it is never the answer a client wants in the meeting.

The better plan: pair from the start

The cheapest version of this is not a rescue at all. If you are going to build with AI tools anyway — and you should, they are fast — put an engineer alongside from the beginning. They review what is generated, fix what is quietly broken, and steer the handful of decisions that are expensive to reverse. You keep the speed. You skip the rebuild.

That is roughly the whole argument for how we work: the tools changed what one person can produce in a weekend, and they did not change which decisions are expensive. Those are still worth having someone in the room for.