Your vibe-coded app is 80% done. The last 20% is where it gets expensive.

Vibe-coding tools like Lovable, Replit, Cursor, etc. get you to a working-looking app remarkably fast. The trouble is what they leave out. The last 20% is not tidying up after a sloppy coder. It is everything the tool was never asked to think about: getting the thing into production, standing up to real users at scale, the edge cases nobody specified, security and data protection, and code a team can actually maintain. That is the expensive part, and it is the part the tools were never built for.

We hear this constantly from founders who arrive with something that demos beautifully and falls over the moment a real user touches it. It is not a new problem. It is the oldest problem in software wearing new clothes.

An old problem in new clothes

On our podcast, The Humans Behind the Tech, I spoke to Ben Burch, co-founder of the community platform Allegr and someone who has built software for the best part of two decades. He uses AI tools to build things himself now, and he put the pattern better than I could:

"You nearly think you've got there, and that last task takes you all the time you thought you'd saved."

That matches what we see every week. The first 80% arrives almost for free. Then you reach the part the model could not do for you, and the saved time quietly flows back out.

He is not the only experienced voice saying it. Nick Sales, a fractional CTO who has run technology for global businesses and now advises startups, was blunt about where the line sits:

"Vibe coding is immensely valuable for many kinds of prototypes. It is not a suitable technique for building high security production quality software... it's devilishly risky. But for prototypes, fantastic."

Jason Margolin, a former Meta engineer who now builds AI products with startups, draws the same line. He is building an AI tool that answers GP phone lines, and he is clear about where the real work lived:

"It's one thing building an AI product that anyone could put together in a day through vibe coding, but it's actually productionising it and going through all the scale challenges that you have with a product like that."

Three people who build software for a living, none of them anti-AI, all saying the same thing: the tools are brilliant at the prototype and were never built for the product.

So what actually is the last 20%?

This is the part founders underestimate, because on screen the app already looks finished. The missing 20% is not visible in a demo. It is the work that turns a thing that runs on your laptop into a thing that survives contact with the real world.

Getting to production, and to scale. A prototype has to work once, for you. A product has to work a thousand times a minute, for people you will never meet. The difference between something that works on your screen and something that works for ten thousand users at once is the difference between a prototype and a product, and it is most of the job. Vibe-coded apps routinely hit a wall as they grow: fine for a hundred users, falling over at ten thousand, because nobody thought about database queries, caching or load when the goal was a working demo.

The edge cases nobody specified. AI generates for the happy path, the version where every user does exactly what you imagined. Real users do not. They paste in the wrong format, double-click, lose their connection, or try to break things on purpose. The model cannot anticipate those paths because it does not know your business. As Jason puts it, you tell the AI what to do "and it will just try and do it to the best of its ability, but it doesn't understand the business and how it operates and what systems they're using." A checkout that quietly accepts a negative quantity is the kind of thing a human tester catches in five minutes and a happy-path prototype never will.

Security and data. This is where the gap is most dangerous, because the failure is invisible until it is catastrophic. The large majority of vibe-coded apps ship with at least one security vulnerability, with some studies putting the figure above 90%, and the reason is structural: a tool racing to produce a working result is not pausing to ask whether it is a safe one. Jason points to the real-world version of this: a vibe-coded app, popular with women, that leaked deeply personal user data. The most prominent example, the dating-safety app Tea, exposed tens of thousands of users' images, including government ID photos, along with private messages. "You don't know you're even using an insecure bit of software that was vibe coded," as Jason says. A prototype that leaks is an embarrassment. A product that leaks is a liability with your name on it.

‍

Code a team can run. A demo only has to work today. A product has to be changed, fixed and extended for years, by people who were not in the room when it was built. That requires code a human can read and reason about, which, as we will see, is exactly what vibe coding tends not to leave behind.

What we find when we look under the hood

‍

When we audit a vibe-coded build, the same problems come up again and again, and they are the same ones other engineers report when they review this kind of code. A few in particular explain why the final stretch costs so much.

Redundant code that never gets deleted. Every time you ask the tool for a change, it tends to add rather than remove. Ask for a button to move and the old one often stays in the code base, dead but still there. The model has no real memory of the architecture it built yesterday, so each prompt starts fresh, and three features that each make sense on their own can combine into a mess. Layer enough of those requests and you get what Jason calls "a spaghetti mishmash of code," so tangled that he would "rather build it again from scratch, because I know that the building blocks are in there correctly."

Fragility once it grows. A small prototype is easy to change. A larger one is not. Past a certain size, vibe-coded builds become tightly and invisibly coupled, so changing one thing breaks another somewhere you were not looking. Jason sees it constantly: you make an edit and "lots of things break and you start seeing bugs" elsewhere in the system. For a non-technical founder this is close to unmanageable, because the fix for one break tends to create the next, and you cannot see why. What felt like fast progress at the start turns into a game of whack-a-mole you have no way to win.

Security gaps, especially when agents do the building. The models are getting better at this, but insecure patterns still ship: hardcoded keys, missing authorisation checks, backend endpoints left open. There are well-documented cases of credentials committed to a public repository and found by automated scrapers within minutes, running up large bills before anyone noticed. The more autonomous the build, the more slips through, because an agent chasing a working result is not stopping to ask whether it is a safe one.

Behaviour you never intended. The tool does exactly what you asked, not what you meant, and because you cannot read the code, you do not catch the gap until a user does. Jason describes inheriting a vibe-coded build as opening "a million lines of code" where "you can't ask it, well, why did you do that?" In a normal team, someone explains why a decision was made and you build on it. With a wall of generated code, that context is simply gone.

None of this is exotic, and none of it means AI writes bad code. It writes the 80% that looks finished and leaves the 20% that decides whether you have a product.

What to do with a prototype that's stuck

If you have built something on one of the vibe coding tools and it has stalled at the demo stage, you have three real options: keep grinding at the last 20% yourself, throw it away and start again, or have someone audit what you have and tell you honestly which parts are worth keeping.

That third option is what we do. Our vibe code audit looks at what you have built and tells you straight what is worth keeping and what is not. We will be honest with you about that: most of the time, little of the generated code itself survives the move to production, and no engineer relishes inheriting a wall of someone else's machine-written code. Now and then a specific component earns its place. But what almost always carries over is worth more than the code anyway: a validated idea, the product decisions you have already made, the screens and flows, and a clear picture of the data you actually need. You have proved there is demand and made the expensive mistakes cheap, and that makes a proper build faster, cheaper and far lower risk than starting from a blank page.

So rather than guess, you start from an honest answer instead of another late night chasing a bug you cannot see. And fixing these things before launch is far cheaper than fixing them after, when the users, and the data, are already real.

We are also building something to make this faster: a way to take what you have vibe-coded and carry more of it across into production-grade code than a rebuild from scratch normally would. More on that soon.

The prototype was not wasted. It did its job, and it got you further, faster, than you could have alone. It simply is not the product yet, and the 20% that remains is the part we are here for.

‍

Built something with AI and need it to be real? Book a vibe code audit and we'll tell you straight what's worth keeping.

This post draws on conversations with Ben Burch, Nick Sales and Jason Margolin on The Humans Behind the Tech, the Old.St Labs podcast.

‍