Should you fix or rebuild a vibe-coded app?

For most vibe-coded apps that already have real users, fixing is the safer first move, and a rebuild is worth it only for the parts that cannot be repaired. A full rewrite throws away years of small decisions the app has absorbed, and it leaves you without a working product while the new one is built. The way to decide is to have someone read the code and write down which parts are sound, which need repair and which need replacing, before you commit to either.

Why is a full rewrite usually the riskier choice?

A full rewrite means paying twice for the same product and running without improvements while you wait. Joel Spolsky wrote in 2000, in Things You Should Never Do, Part I, that rewriting from scratch is the "single worst strategic mistake" a software company can make, using Netscape's decision to rewrite its browser as his example. He also observed that "it's harder to read code than to write it", which is why a new team looking at working code is tempted to start again when the real issue is only that they haven't read it yet.

That article is about a company's own flagship product, and your app is probably smaller, so we'd treat it as a caution and not a law. It does fit what we see with AI-built apps, though: the code looks unfamiliar to a new developer, so a rebuild feels cleaner, and the rebuild then has to rediscover every edge case the old app already handles.

When is a rebuild the right call?

A rebuild is right when the foundation cannot carry what you need next, and a repair would cost about as much as starting that part again. Some signs a developer will look for:

• The data is stored in a way that cannot represent your business, for example one table doing the job of five, so every new feature needs a workaround.
• Security depends on the structure itself, such as no separation between what one customer and another can see, and fixing that touches every screen.
• The app is tied to a platform or service you have outgrown or cannot afford, and moving off it means rewriting most of it anyway.
• Nobody can run it locally or deploy it repeatedly, which makes every fix a gamble.

Even then, the answer is often to rebuild one part and keep the rest. Martin Fowler describes this as the strangler fig pattern: you add new functionality beside the old system and gradually move work across, and he says he and his colleagues prefer a gradual approach to replacing a legacy system. Your customers keep using the app the whole time.

When is fixing enough?

Fixing is enough when the app does the job and the trouble sits in particular places: a missing security setting, a payment webhook that isn't verified, secrets stored where they shouldn't be, no backups, or a feature that breaks another because two pieces of code share too much. Those are repairs, and they are usually found by reading the code, and they are cheaper than they feel when you first hit them.

Two examples from vendor documentation show how specific these repairs can be. Supabase's row-level security guide is the page to check if your app stores customer data there, because a table without it can be readable by anyone with a grant on it. Stripe's webhook documentation explains why your server should verify that each event really came from Stripe. Neither of those needs a rebuild, and both are the kind of thing an audit finds.

What does a Rescue audit settle before you decide?

It replaces a guess with a written answer. The We UC Rescue audit is a fixed price of £2,500 + VAT, and the fee is deducted from the first phase if you go ahead with us on the fix. We review security, data, hosting, code, payments and integrations, and running costs, then give you a written report, a priced plan and a walkthrough call. Nothing is changed during the audit, and we need read access to your code and hosting.

The report ends with one of three outcomes. We fix it, starting with the urgent problems and then working in fixed-price phases. We rebuild only the parts that need it. Or you take the plan and use it with your own developer, because the report is yours either way. In our experience a lot more can usually be kept than people fear, but the report says what we actually found and not what we hoped to find.

We UC is a UK software company, and the team doing the review is the team that keeps Olatti, a UK business phone network, and Quenta, an app that posts receipts into Xero, running in production. We use AI heavily for speed, and an engineer reviews every change before it ships.

Common questions

Did we make a mistake by building it with AI tools?

No, you didn't, and you got further than most people ever do, and AI tools are good at getting something working. The question now is only whether it is ready for the customers and money that depend on it.

Can we keep using the app while it is being fixed?

Usually yes, because fixing in phases and replacing one part at a time both leave the running app in place. The audit report sets out the order and what each phase touches.

Who owns the code afterwards?

You do, since your code, your repository and your accounts stay yours, and the audit report is yours whether or not you work with us afterwards.

Does We UC publish prices for building or running software?

Not yet, because Build is scoped first and priced in fixed phases, and Run is a monthly retainer, so you ask us for a quote on either.

If your app has paying users or customer data and you aren't sure whether to fix or rebuild, you can book a Rescue audit, or tell us what you've built and we'll say whether an audit is the right first step.