Refactor the Backend or Rebuild From Scratch? Deciding on a Broken Vibe-Coded App

The two options, briefly

Refactoring reorganises the code you already have, without changing what your users see. Rebuilding starts from an empty folder on a sturdier foundation, keeping your designs and your validated ideas, but none of the code.

Almost every rescue firm I looked at defaults to refactoring, and the one that sells rebuilds defaults to rebuilding. The commercial model predicts the recommendation, which is why it pays to understand the decision before asking anyone to make it.

What decides it is whether the code can be changed safely

Automated tests are what makes that possible. Without them, nobody can tell whether today's fix broke last week's feature, which is why the fix-break loop feels endless. Most vibe-coded apps ship with none.

Michael Feathers, whose 2004 book is the standard reference on inherited code, defines legacy code as code without tests. Not old code, not ugly code. Untested code, where every change is a guess.

So the first question is whether your app's behaviour is recorded anywhere a machine can check it, not how bad the code looks to a developer.

We grade the app before quoting on anything. The Platform Discovery Sprint produces a Code Health Scorecard with a fix, refactor or rebuild verdict for each part of the app, rather than one verdict for the whole thing. If you have a CTO or a technical advisor, that is the document to put in front of them, because it shows the reasoning per component rather than a conclusion to take on trust.

Three numbers worth asking for

SonarQube, a widely used code scanner, grades a codebase from A to E on how much work it would take to fix everything wrong with it. An A means repairs would cost 5% or less of the effort that went into building it. An E means more than half.

Change failure rate is how often a change to the live app breaks something. Google's DORA programme benchmarks it annually, and in the 2024 report the strongest teams sit at around 5% or below. If every second change costs you something that was working, you are a long way outside that.

A 2022 study from the team behind CodeScene covered 39 commercial codebases and 30,737 files. Poor quality code carried fifteen times more defects, and fixing an issue inside it took 124% more development time. Those are averages across large systems, so read them as a direction rather than a prediction about your app.

We run SonarQube, PHPStan and npm audit during the Sprint, then review the output by hand, because a scanner finds problems without understanding your business.

What outranks the code

Live users change the maths before anyone opens the codebase. Once your app holds personal data, UK data protection law already applies, and copying customer records into a new system is itself processing. The duty to keep that data secure covers the migration, not only the finished product.

A second obligation applies if your app uses AI to process personal data. The Information Commissioner's Office treats new technology of that kind as a marker of higher risk, and combined with another risk factor it requires a documented Data Protection Impact Assessment. How the code was written is irrelevant here. What the app does with data is the test.

Undocumented business rules come next. Every app accumulates rules that exist nowhere except in the code, and a rebuild deletes all of them. You find out which ones mattered when a customer complains.

Delivery risk is the third, and for a funded team it is the one that costs most. A rebuild freezes feature work for its duration, which is a quarter with nothing new to show a board or a customer. Bent Flyvbjerg, an Oxford professor who studies why large projects go wrong, examined 1,471 IT projects for a 2011 article in Harvard Business Review. The average cost overrun was 27%, but one project in six ran to a 200% overrun and almost 70% longer than planned. He found the same pattern on a larger set in 2022.

That work covers corporate IT rather than startup rebuilds, and nobody has produced an equivalent study for small apps. Anyone quoting you a failure rate for rebuilding an MVP is guessing.

The Discovery Sprint runs three weeks and gives you a 15 to 20 page report with a route to production. It costs £4,500, credited in full against any build that follows, set against the cost of committing a quarter to the wrong option. Rebuilds take 8 to 16 weeks and start at £25,000, with timelines given after the Sprint rather than before. There is more on the tiers in what it costs to fix a vibe-coded MVP.

The middle option, and when it works

You can also replace an app gradually, growing the new version around the old one until nothing of the original is left. Martin Fowler named this the Strangler Fig pattern, and it is the standard answer to rewrite risk.

It was designed for large corporate systems. Microsoft's architecture guidance says it may not suit a small system where replacing the whole thing is simple, and Amazon's says much the same. Worth knowing before someone sells you a phased migration for an app that would take six weeks to replace.

The more useful middle ground for AI-built apps comes from where the damage sits. The front end, the screens your users see, is often sound and exports as standard React. The failures cluster behind it, in logins, database design, error handling and security.

Where that holds, we rebuild the back end on Laravel and keep your existing React screens via Inertia.js. The rebuild then covers the part that is broken, and you keep the part that is not.

How to make the call

Write down what your app currently does, including the rules that only exist in your head. Get a graded read on each part rather than one verdict on the whole. Weigh that against your live users, your data obligations, and how long you can go without shipping.

Most vibe-coded apps do not need throwing away. The screens usually survive. The back end usually does not, and replacing that is a far smaller job than starting again.

If you would rather not work through it alone, our App Assessment Call is free, takes 30 minutes, and ends with a straight answer on whether your app can be rescued, needs rework, or should be rebuilt. Sometimes the answer is that you do not need us, and we will say so.