From vibe-coded MVP to production: the hard 20% that takes 80% of the pain

Your AI-built prototype works beautifully in the demo. Getting it to survive real users, real data and real traffic is a different discipline — and it is where most "almost done" projects stall for weeks.

Tools like Lovable, Cursor, Replit and Claude Code have collapsed the distance between an idea and a working app. What used to take a team a month now takes a founder a weekend. That is genuinely one of the most important shifts in software of the last decade — and if you have shipped a working product this way, you have done something real.

But "it runs" and "it's in production" are not the same claim. Prototyping tools optimise for speed of creation, not for the properties a system needs once other people depend on it. The gap between the two is small in line count and enormous in consequence. It is the classic 80/20: the last 20% of the work carries 80% of the risk.

What the last 20% actually is

When we assess AI-generated codebases, the missing pieces are remarkably consistent. They cluster into a familiar set of areas:

1. Security

Secrets committed to the repository. Authentication that checks a token but never validates it properly. Endpoints with no authorization at all. CORS: *. No rate limiting, so one script can exhaust your database. These are not exotic — they are the default state of code written to make a demo work, and they are exactly what an attacker looks for first.

2. Architecture

AI tools optimise for making the current feature work, not for the shape of the system after fifty features. The result is often a tangle: no clear module boundaries, business logic mixed into the UI, and decisions baked in early that quietly cap how far the product can go. Bad architecture is not a bug you can see — it is a tax you pay on every future change. Refactoring it into clean, modular structure is what keeps you (and your AI tools) able to keep building.

3. Data model and database

This is the one vibe-coded apps get wrong most — and the most painful to fix once you are live. Schemas designed to make one screen work often fall apart when real data arrives: missing relationships, no constraints to protect integrity, no indexes so queries crawl, and no safe way to change the shape without risking the data already in there. Getting the data model right early is worth more than almost any other fix, because everything else is built on top of it.

4. Tests

Most prototypes have zero automated tests. That is fine at the prototype stage and fatal afterwards: every new feature you add has a growing chance of silently breaking something that used to work. A test suite is not bureaucracy — it is the thing that lets you keep shipping quickly without fear.

5. Error handling and observability

Happy-path code assumes the network is up, the input is valid and the third-party API always answers. Production is where those assumptions go to die. Without structured logging, health checks and error tracking, your first sign of a problem is an angry customer — not a dashboard.

6. Deployment

"It works on my machine" is not a deployment strategy. Reproducible builds, managed configuration and secrets, database migrations, and a way to roll back safely are what turn a laptop project into a system you can operate.

7. Performance and scale

The query that is instant with ten rows melts at ten thousand. N+1 queries, missing indexes and no caching are invisible until real data arrives — and then they are the whole problem.

The prototype proves the idea. The hard 20% proves it can be trusted with someone's business.

Why it stalls

This work stalls not because it is impossible, but because it is a different kind of work. Building features is creative and fast; hardening a system is careful and unglamorous. It also requires judgement earned from operating real systems — knowing which of a hundred findings actually matters, and in what order. That judgement is hard to vibe your way to, because the feedback loop (a breach, an outage, a corrupted migration) is slow and expensive.

How to get through it

The path is not to stop building. It is to separate the two disciplines and let each be done well:

• Assess honestly first. Before you fix anything, get an objective, itemised picture of where the codebase actually stands across security, tests, architecture, infrastructure and scale.
• Fix in priority order. Close the critical security holes and data-loss risks before the cosmetic ones. Most of the risk lives in a handful of findings.
• Automate the safety net. A test suite plus CI means future changes — including the ones you vibe next week — can't quietly regress production.
• Make it operable. Reproducible deploys, monitoring and rollback turn "hope it stays up" into "we'll know and we can fix it."
• Keep someone responsible. Production is not a one-time event. The most valuable thing you can have once you are live is a team that owns the production environment while you keep building.

None of this means throwing away what you built. Quite the opposite: the value is in the product you created. The hard 20% simply makes that value safe to depend on.