Prototype to Production

From Vibe-Coded Prototype to Production: What Actually Has to Change

You built something real with AI tools, and then it started falling apart around 5–10k lines. 'Vibe decay' is real. Here's what genuinely has to change to make an AI-built prototype ready for real customers and real money.

James Levine6 min read

From Vibe-Coded Prototype to Production: What Actually Has to Change

Something genuinely new is happening. Founders who have never written a line of code are building working software, real functioning products, by describing what they want to AI tools. A year ago that was a fantasy. Now people show up to my calls with an app they actually built themselves, and it works.

And then, somewhere around 5,000 to 10,000 lines of code, it starts to fall apart.

Features that worked yesterday break today. Fixing one thing breaks two others. The AI starts confidently "fixing" code it doesn't understand and makes things worse. Founders have a name for this now: vibe decay. The vibes were great right up until they weren't.

If that's you, first: well done. You validated something real without spending £50k. That's genuinely impressive and it's a huge head start. But turning a vibe-coded prototype into something you can safely put real users and real money through is a different job. Here's what actually has to change.

Why vibe-coded apps hit a wall

It's not that the AI is bad. It's that generating code and engineering a system are different activities.

AI tools are brilliant at producing the next plausible chunk of code for a small, well-described task. But they have no persistent model of your whole system. As the codebase grows, three things compound:

  1. No architecture. Each feature was bolted on in isolation. There's no consistent structure, so everything is tangled together. Change one thing, and unrelated things break, because everything secretly depends on everything.
  2. No tests. Nothing verifies that yesterday's features still work. So every change is a gamble, and the gambling gets worse as the app grows.
  3. No memory of intent. The AI doesn't know why something was built a certain way. Neither, six weeks later, do you. So "fixes" fight the original design.

The result is an app that's fine as a demo and dangerous as a business. The good news: it's fixable, and you don't have to start over.

What actually has to change

Here's the honest checklist. Not all of it is glamorous, but this is the difference between a demo and a product.

1. Security: this is the urgent one

Vibe-coded apps are, almost without exception, full of security holes. The AI wasn't thinking about attackers; it was thinking about making your button work. Before real users touch it, you need:

  • Secrets out of the code. API keys, database passwords, and tokens are almost always hardcoded in AI-built apps. They belong in environment variables, never in the repository.
  • Real authentication and authorisation. Not just "there's a login page." You need actual checks on the server that stop user A reading user B's data. This is the single most common catastrophic flaw I find.
  • Input validation everywhere. Every field a user can touch is a potential attack. Validate and sanitise on the server, not just the browser.
  • Rate limiting. So one bad actor can't hammer your app or run up a ruinous bill.

I cannot stress this enough: a data breach can end your company before it starts. This is the part you fix first.

2. Architecture: untangle it before you add anything

The tangle is why every change breaks something. Making it solid means giving it a real structure: separating your data, your business logic, and your interface so they stop leaking into each other. This is unglamorous refactoring work, but it's what makes the app changeable again, which is the whole point of software.

You don't need microservices or anything fancy (see scaling architecture without a rewrite). You need a clean, boring, well-organised monolith. That's it.

3. Tests: so you can move without fear

This is the change founders underrate the most. Automated tests are what let you (and any future developer) change the app without holding your breath. They catch the "I fixed X and broke Y" problem before your users do. Even modest test coverage on your critical paths (signup, payment, the core workflow) transforms how safely the app can grow.

4. A real data model

Vibe-coded apps often store data in whatever shape was convenient at the time. That works until you have real volume and real reporting needs, then it becomes a nightmare to untangle. Getting the data model right, even just cleaning up what's there, pays off enormously and gets harder the longer you leave it.

5. Error handling, logging, and monitoring

When something breaks in production, and it will, you need to know, ideally before your users tell you. That means centralised error logging, sensible error messages, and monitoring that alerts you when things go wrong. AI-built apps almost never have this. It's the difference between "a user emailed us angry" and "we caught and fixed it in ten minutes."

6. Deployment you can trust

Manually copying files to a server is how prototypes ship and how businesses get hurt. You want an automated, repeatable deployment with the ability to roll back instantly if something goes wrong. It's not hard to set up once, and it saves you from the worst Friday-afternoon disasters.

For the full, exhaustive version of this, I've written a complete prototype-to-production checklist.

The good news: you don't start over

Here's what I want every vibe-coding founder to hear. You do not need to throw it all away. That prototype did the hardest thing in business: it proved something works. The code underneath might need serious work, but the product knowledge, the validated idea, the real users? Those are gold, and rewriting from scratch throws them away along with the mess.

The right move is almost always to stabilise, secure, and refactor incrementally, not rebuild. Lock down the security holes first, add tests around the parts that matter, untangle the architecture piece by piece, and keep the app running the whole time. I've done this on real products, including consumer apps in production. For instance, the ChargedUp order-at-table build had to be genuinely solid and secure because real customers were paying through it.

When to bring in help

You can take a vibe-coded prototype a surprisingly long way yourself. Bring in a professional when:

  • You're about to take real payments or handle personal data
  • You're getting traction and can't afford it to fall over
  • You're raising money and investors will look under the hood
  • You're simply stuck, and the app fights you every time you change it

That's the exact transition I help founders through: sometimes as a one-off hardening project, sometimes as an ongoing fractional CTO relationship. Either way, the goal is the same: keep everything good about what you built, and quietly fix everything that would have hurt you.

Show me what you've built and I'll tell you honestly what it needs →

About the Author James Levine is a senior full-stack developer and fractional CTO based in Surrey. Ex-Amazon and Ticketmaster, he specialises in taking prototypes, increasingly AI-built ones, and turning them into secure, scalable software real businesses can rely on.