Vibe coding is the new spec
Something genuinely useful has happened. A founder with an idea and no engineering team can now describe what they want, and have a working version of it by the end of the week. Not a wireframe or a clickable mock-up — something real enough to put in front of a customer, take money through, and raise against.
The instinct in engineering circles is to sneer at this. That instinct is wrong. But so is the assumption that what you have built is the product.
The prototype is the specification
Writing requirements is one of the least reliable activities in software. Everyone has sat in the meeting where a document is agreed by people who each understood it differently, then spent the following three months discovering that.
A working prototype removes the ambiguity. Nobody has to imagine what the onboarding flow does — they can click it. Nobody argues about whether the dashboard should show the chart or the table, because it is right there being wrong. Decisions that would have taken a fortnight of documentation get made in an afternoon of using the thing.
That is the real shift. Vibe coding has not replaced engineering; it has replaced the spec. And it is a far better spec than the document it replaces, because it encodes intent in a form that cannot be misread. Handing an engineering team a working prototype and saying “this, but properly” is a genuinely superior brief.
So build it. Validate the idea, win the early customers, get the funding. The mistake is what comes next.
Where it stops being enough
The code that got you to ten users probably will not get you to a thousand.
The prototype was optimised for one thing — arriving quickly — and every trade-off that made it fast is still in there. Those trade-offs are invisible while you have a handful of friendly users and become expensive at precisely the moment you succeed.
Security is the one that should worry you most. It is the equivalent of a beautifully finished house with no locks on the doors. API keys committed into the codebase or exposed to the browser. Endpoints that check whether you are logged in but not whether the record you asked for is yours. It looks completely fine from the outside, right up until it very much isn’t.
Performance holds up at five concurrent users and collapses at five hundred. Inefficiencies that are imperceptible at small scale — a query inside a loop, no indexes, everything loaded on every request — turn into timeouts the week your marketing works.
Data integrity is the failure you cannot undo. A schema assembled as you went, without constraints or relationships, will accept contradictory records quite happily. Bugs cost you an afternoon; corrupted customer data costs you customers, and no amount of engineering afterwards recovers what was lost.
Maintainability is the tax you pay forever. The code was never written to be read, extended, or handed to somebody else. When you do hire, they will spend a large share of their first months working out what the existing logic actually does — which you are paying for, at senior rates, instead of new features.
Nothing tells you when it breaks. No automated tests, no error monitoring. You find out from a customer, which means every failure is also a trust problem.
Compliance does not care how you built it. GDPR, accessibility, cookie consent, data residency, the lawful basis for what you are storing — all of it applies from your first real user, whether or not anyone thought about it.
And the platform is not yours. Building inside a proprietary environment means your product’s future depends on that company’s pricing, terms and continued existence. Portability is worth thinking about before you have customers depending on you.
“Working” and “production-ready” are different words
It is worth being precise about the distinction, because the gap between them is where founders get hurt.
Working means it does the thing when you try it.
Production-ready means it handles real users, with real data, reliably, safely and legally — and keeps doing so when volume increases, when something fails, and when someone new has to change it. In practice that means a staging environment separate from live, deployments that are repeatable rather than manual, error monitoring that tells you before your customers do, authentication and authorisation that hold up to someone actively probing them, a database designed to grow, and code structured so a second engineer can contribute.
None of that is visible in a demo. All of it determines whether the business survives its own traction.
What to actually do about it
Not “rebuild it properly”, which is the reflexive advice and usually the wrong one. You built the prototype to learn, and most of what you learned is worth keeping.
The useful move is to find out what you have before you scale it. Get someone competent to look honestly at the security posture, the data model, the dependencies and the parts that will break first under load. That produces a ranked list, and the list is almost never “start again”. It is usually a handful of things that genuinely must be fixed before more customers arrive, a larger set that can wait, and a few that were fine all along.
Then fix them in that order, while continuing to sell. Your job as a founder is to be out in the market, not wrestling with technical debt you cannot yet see.
Vibe coding got you a specification that actually communicates, and customers who prove the idea. That is a strong position. Just be clear-eyed that you have validated the idea, not built the business — and that the distance between the two is engineering work someone still has to do.