You launched. People signed up. Then the messages started.

You fix the login bug and checkout stops working. You fix checkout and the dashboard shows the wrong totals. A customer emails about something nobody on your test list ever tried, and you can't work out how they even got there.

If that's where you are, you're not unlucky and you're not doing it wrong. Taking a vibe-coded app to production exposes the same gaps again and again. Tools like Lovable, Bolt, Replit, Cursor, Fable and Atlas are built to get you to a working demo fast. They're very good at that. Production asks for different things.

This guide explains why every fix seems to break something else, and why real users find problems your testers missed. It ends with a production readiness checklist you can work through this week, in the order that protects your users and your revenue first.

Why every fix breaks something else in a vibe-coded app

Every fix breaks something else because AI tools tend to write new code rather than reuse what's already there. The same logic ends up in several places and nothing tells you what depends on what. With no automated tests, nothing warns you when a change breaks a part of the app you weren't looking at.

That's the short version. Here's what it looks like underneath.

The same logic, written 5 different ways

Ask an AI tool for a new feature and it will usually write fresh code for it, even when similar code already exists. So the rule for calculating a price, or checking whether someone is logged in, ends up copied into 3 or 4 places. Each copy is slightly different.

When you fix 1 copy, the others carry on as before. Your app now behaves 2 different ways depending on which screen someone is on.

The wider data points the same way. In its research into AI-assisted coding, GitClear analysed 211 million changed lines of code and found an 8-fold rise in duplicated code blocks during 2024. It was also the first year that copied and pasted code outnumbered code that had been moved and reused. More copies means more places for the same bug to hide.

No tests means no safety net

In a professionally built product, automated tests check the important journeys every time someone makes a change. Sign up, log in, pay, see your data. If a change breaks any of them, the tests fail before a customer ever sees it.

Many AI-built apps have none. The tool showed you a preview, you clicked around, it worked and you moved on. That check happened once. It doesn't happen again when the next change goes in, so you only find out something broke when a user tells you.

The AI fixes what it can see, not the whole system

When you paste an error into your AI tool, it sees that error and a slice of your code. It doesn't see everything else that relies on the function it's about to change. So it fixes the symptom in front of it, confidently, and the knock-on effect lands somewhere else.

Professional developers know this frustration well. In Stack Overflow's 2025 Developer Survey of more than 49,000 developers, the top complaint about AI tools was solutions that are almost right but not quite, cited by 66%. The next biggest, at 45%, was that debugging AI-generated code takes longer. If experienced engineers find AI-generated code bugs hard to untangle, it's no surprise founders end up going in circles.

Why real users find what your testers didn't

Real users find problems your testers missed because testers follow the path you designed, and real users don't. They bring messy data, old phones, poor signal and their own ideas about what order to do things in. They also turn up at the same time as each other, which a small test group can't recreate.

Your testers weren't careless. They were testing a demo, and a demo only has to work when people use it the way you planned. Here's how the 2 compare.

• Signing up: testers use a clean email and a simple name. Real users have apostrophes and accents in their names, or paste an email with a space on the end.
• Devices: testers use a recent laptop on fast Wi-Fi. Real users are on a 4-year-old phone on a train with patchy signal.
• Order of steps: testers follow the steps in order. Real users hit back mid-payment, refresh, open 2 tabs and come back a week later.
• Data: testers add a few neat records. Real users upload a huge photo, paste 5,000 words into a short field and leave required fields empty.
• Timing: testers test alone. Real users arrive with hundreds of other people after your newsletter goes out.
• Access: testers look at their own data. Real users change a number in the web address and see someone else's.

That last one is the one to worry about. It's an easy gap to leave in an AI-built app, and it isn't a bug. It's a data breach.

Timing is the other blind spot. 2 people buying the last item at the same moment, or 2 tabs saving the same record, create problems that can't appear when 1 person tests on their own. They only show up once you have real traffic, which is exactly when you can least afford them.

Hardening, not rebuilding: what production-ready means for a vibe-coded app

Production-ready means your app keeps working, keeps data safe and can be changed without fear while real people rely on it. For many AI-built apps, getting there is a hardening job, not a rebuild. When we look at AI-built apps, the screens, flows and core idea often hold up fine. What's missing is the layer underneath that a demo never needed.

That missing layer is where vibe coding technical debt builds up. Every quick fix that skips it adds a little more, and you pay the interest in time spent firefighting instead of building.

The wider industry is seeing the same trade-off. Google's DORA research found that as teams adopted AI, delivery stability went down: every 25% rise in AI adoption was linked to roughly a 7.2% fall in stability. The 2025 report found AI now helps teams ship faster, but it's still associated with less stable releases. Speed and stability don't arrive together by default. You have to build the second one in.

Do you need to harden or rebuild?

Hardening is usually the right call when the app does what users need, the data structure makes sense, and the problems are about security, reliability and confidence to change things.

A rebuild is worth discussing when the data model is wrong at its core or the app needs something its platform can't support. It's also worth it when untangling the code would cost more than starting again with what you've learned. Even then, the prototype isn't wasted. It's the best spec you'll ever have, because real users have already tested it.

The production readiness checklist for a vibe-coded app

Use this as a working list. You don't need to do it all at once, and some of it will need a developer, but you should be able to answer yes or no to every line.

1. Stop the damage

• Version control. Your code lives in Git (on GitHub, for example) and every working change is saved, so you can roll back when a fix goes wrong.
• Backups you've tested. Your database backs up automatically, and someone has restored a backup to prove it works.
• Separate staging and production. You test changes on a copy of the app, not on the live version your customers are using.
• Error monitoring. A tool like Sentry tells you when something breaks, so you hear about it before your users email you.

2. Protect your users

• Every request checks who's asking. Hiding a button isn't security. The server must check that the logged-in user is allowed to see or change that data, every time.
• Users only see their own data. If you use Supabase, row level security is switched on with policies on every table.
• Secrets stay off the front end. No API keys, service keys or passwords in code that runs in the browser.
• Inputs are checked on the server. Forms are validated where the data is saved, not just on the screen.

This group matters more than it looks. Veracode's 2025 GenAI Code Security Report tested more than 100 AI models. When a secure option existed, the models chose an insecure way of writing code 45% of the time. Newer models were better at writing code that works, but no better at writing code that's secure.

3. Make changes safe

• Tests on the journeys that make money. Start with sign up, log in, payment and your core feature. 5 good tests beat none.
• Shared logic lives in 1 place. Prices, permissions and calculations are written once and reused, not copied.
• 1 change at a time. Small, separate changes you can test and undo, rather than a big prompt that touches 20 files.

4. Meet your UK obligations

• UK GDPR. You know what personal data you collect, why you collect it, where it's stored and how a user can get it deleted.
• A privacy notice that matches what your app actually does, not a generic template.
• Cookie consent that holds back non-essential cookies until someone agrees.
• Data location. You know which country your database and third-party services keep data in.

5. Prepare for growth

• Payments handle failure. Declined cards, abandoned checkouts and payment notifications arriving twice all leave your data in a sensible state.
• Rate limits on log in, sign up and anything that costs you money per request, such as AI features.
• A basic load test. You know roughly what happens when 10 times your current users arrive at once.

How to fix a vibe-coded app: what to tackle first

Fix things in the order they could hurt your users and your business. A slow page is annoying. A leak of customer data can end a company. When everything feels urgent, this order keeps you on track:

1. Data exposure. Anyone seeing data that isn't theirs, or keys sitting in the browser. Fix these today.
2. Payments. Taking money without delivering, or delivering without taking money.
3. Data loss. No backups, or changes that can overwrite records.
4. Broken core journeys. Anything that stops someone signing up, logging in or doing the main thing your app is for.
5. Speed and polish. These matter, but they can wait until the foundations are safe.

While you work through the list, change how you use your AI tool. Commit before every prompt. Before you accept a change, ask what else uses the code it's about to touch. Keep each request small. These habits won't close the gaps on their own, but they'll stop you adding to them.

If you're earlier on and still deciding what comes after the prototype, our founder's guide, You've Vibe Coded an App, Now What?, covers the bigger picture.

Get your app ready for real users

The chaos after launch isn't random. Fixes cascade because the same logic lives in several places and nothing tests it. Real users find what testers missed because they don't follow your script. And many AI-built apps don't need throwing away. They need the production layer the demo never had.

If you'd like a second pair of eyes, our Foundation Audit includes a production-readiness pass. It checks your app against the kind of list above and gives you a prioritised plan. You'll know what to fix first, and you can tackle it yourself or with our software development team. It's available on request, so get in touch and tell us what you've built.

FAQs

Can a vibe-coded app go to production?

Yes. An AI-built app can run in production once it has the basics in place: proper authorisation, separate environments, backups, monitoring and tests on the key journeys. What you've built is often a solid starting point. It just wasn't finished for real users.

Should I fix my AI-built app or rebuild it?

In many cases, fix it. If the app does what users need and the data structure makes sense, hardening is faster and cheaper than starting again. A rebuild is worth considering when the data model is wrong at its core or the platform can't support what you need next.

Why does fixing one bug create another?

Usually because the same logic exists in several places and there are no automated tests. You fix 1 copy while another carries on, or your change affects code that relied on the old behaviour. Tests on your key journeys and pulling shared logic into 1 place break the cycle.

Is AI-generated code secure?

Not by default. Veracode's 2025 research found AI models picked an insecure approach 45% of the time when a secure one was available. Treat AI-generated code like work from a fast but junior developer: useful, but it needs reviewing before it handles real data.

How long does it take to make a vibe-coded app production-ready?

It depends on the size of the app and how many gaps it has. The urgent security fixes can often be done in days, while tests, monitoring and cleanup take longer. An audit first tells you what you're actually dealing with, so you're not guessing at a timeline.

Can I keep using Lovable or Cursor after launch?

Yes. The difference is how you use them: small changes, version control, a staging environment and tests that run before anything goes live. The tool stays the same. The safety net around it changes.