Vibe coding is the new spec
Something really useful has happened. A founder with an idea and no engineering team can now describe what they want and have a working version by the end of the week. Not a wireframe or a clickable mock-up, but something real enough to put in front of a customer, take money through, and raise against.
A lot of engineers like to sneer at this. They’re wrong to. But so is anyone who assumes what they’ve built is the product.
The prototype is the specification
Writing requirements is one of the least reliable things we do in software. We’ve all been in the meeting where everyone agrees a document, each understanding it slightly differently, and then spends the next three months finding that out.
A working prototype removes the guesswork. Nobody has to imagine what the onboarding flow does. They can click through it. Nobody argues about whether the dashboard should show a chart or a table, because it’s right there being wrong. Decisions that would have taken a fortnight of documents get made in an afternoon of using the thing.
That’s the real shift. Vibe coding hasn’t replaced engineering. It’s replaced the spec. And it’s a far better spec than the document it replaces, because it shows what you mean in a way nobody can misread. Handing an engineering team a working prototype and saying “this, but built to last” is a better brief than anything you could write.
So build it. Test 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 won’t get you to a thousand.
The prototype was built for one thing: speed. Every shortcut that made it fast is still in there. You won’t notice them while you’ve got a handful of friendly users. They get expensive at exactly the moment you start to succeed.
Security should worry you most. It’s like a beautifully finished house with no locks on the doors. API keys committed to the codebase or exposed in the browser. Endpoints that check you’re logged in but not whether the record you asked for is yours. It all looks fine from the outside, right up until it very much isn’t.
Performance holds up at five users at once and falls over at five hundred. Things you’d never notice at small scale, like a query inside a loop, no indexes, or everything loading on every request, turn into timeouts the week your marketing starts working.
Data integrity is the failure you can’t undo. A database schema pieced together as you went, with no constraints or relationships, will happily accept records that contradict each other. A bug costs you an afternoon. Corrupted customer data costs you customers, and no amount of engineering afterwards gets back what was lost.
Maintainability is a tax you pay forever. The code was never written to be read, extended or handed to someone else. When you do hire, they’ll spend a big chunk of their first months working out what the existing code does. You’re paying senior rates for that instead of new features.
Nothing tells you when it breaks. No automated tests, no error monitoring. You find out from a customer, so every failure is also a hit to their trust.
Compliance doesn’t care how you built it. GDPR, accessibility, cookie consent, data residency, the lawful basis for what you’re storing. It all applies from your first real user, whether anyone thought about it or not.
And the platform isn’t yours. Build inside someone else’s proprietary environment and your product’s future depends on their pricing, their terms and whether they stay in business. It’s worth thinking about portability before customers are relying on you.
“Working” and “production-ready” mean different things
It’s worth being clear about the difference, 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 and real data reliably, safely and legally, and keeps doing so as volume grows, when something fails, and when someone new has to change it. In practice that means a staging environment separate from live, repeatable deployments instead of manual ones, error monitoring that tells you before your customers do, logins and permissions that stand up to someone deliberately poking at them, a database designed to grow, and code a second engineer can work on.
You won’t see any of that in a demo. All of it decides whether the business survives its own success.
What to do about it
Not “rebuild it from scratch”. That’s the knee-jerk advice, and it’s usually wrong. You built the prototype to learn, and most of what you learned is worth keeping.
The smart move is to find out what you’ve got before you scale it. Get someone who knows what they’re doing to look hard at the security, the data model, the dependencies and the parts that’ll break first under load. That’s a technical review of the prototype, not a rebuild. It gives you a ranked list, and that list is almost never “start again”. It’s usually a handful of things you must fix before more customers arrive, a bigger set that can wait, and a few that were fine all along.
Then fix them in that order while you carry on selling. Your job as a founder is to be out in the market, not wrestling with technical debt you can’t see yet.
Vibe coding got you a spec that communicates clearly, and customers who prove the idea. That’s a strong position. Just be clear that you’ve validated the idea, not built the business. The distance between the two is engineering work someone still has to do.