Published 20 July 2026

Fix It or Rebuild It? A Decision Framework

Fixing is usually cheaper than rebuilding, because working software already contains decisions you would otherwise have to make again. Rebuilding wins in three situations: the data model no longer matches the product, the same mistake is repeated in every file, or the app is small enough to redo in days.

Our conflict of interest. We sell both remediation and ongoing engineering, so we are paid either way and we are paid more for a rebuild. Every firm in this market has the same incentive, which is why a genuinely neutral version of this guide does not exist. Treat what follows as a starting point, and get a second opinion on any rebuild recommendation, including one from us.

Why the default answer is “rebuild” and why that should bother you

A rebuild is the largest invoice available in this business. It is also easier to scope than a repair, because the scope is “everything” and nobody has to read the existing code to produce a number. A repair quote requires understanding what is actually wrong, which takes real hours before any money changes hands.

So the incentive runs one direction for every vendor you will talk to. That does not make rebuild recommendations dishonest. It does mean the recommendation carries less information than it appears to, and that you should ask for the reasoning rather than the verdict.

The rest of this page is a framework you can run yourself, on your own app, before anyone quotes you anything.

Four questions that actually decide it

Score each one from 0 to 3. Higher means the evidence points toward rebuilding. Answer them about the app you have, not the app you meant to build.

Does the data model still match what the product does?

Open the tables your app writes to and read the column names. Then describe out loud what your product does today. If the two descriptions match, most of your problems are local and fixable. If you are storing the real structure of your product inside a JSON blob, a column named metadata, or a comma-separated string because the schema had nowhere else to put it, you are paying a tax on every feature you add.

0 — The tables describe the product accurately. Adding a field means adding a field.
1 — One or two tables are awkward and there are workarounds you can name.
2 — Several features are implemented against the grain of the schema, and you can point at the code that fights it.
3 — The main entity in your product does not exist as a table. It is assembled at runtime from pieces of other tables.

How much of the code is actually load-bearing?

AI-assisted projects accumulate abandoned approaches. A feature was tried, half-built, replaced, and the first version was never deleted. That code still gets read by you, by the next engineer, and by the model editing the file. If most of the codebase is dead, the app you are deciding about is smaller than the repository suggests, and the rebuild estimate you were given is probably priced against the dead code too.

0 — Nearly everything in the repository runs. You can account for the folders.
1 — There are some unused components and an old version of one page.
2 — You find whole directories nobody can explain, including duplicate implementations of the same screen.
3 — You cannot tell which version of a given feature is the live one without running the app and watching the network tab.

Is the problem localized or systemic?

Write down the last ten things that broke. If eight of them trace back to the same two or three files, that is a localized problem and rebuilding the whole application to solve it is a very expensive way to fix three files. If the ten failures are spread across ten unrelated areas, the same underlying mistake is repeated everywhere, and fixing instances one at a time is an ongoing cost with no end date.

0 — Failures cluster in a couple of modules you could name from memory.
1 — Failures cluster, but the cluster keeps getting bigger.
2 — Failures appear in unrelated areas and share a root cause, such as authorization checked in the browser instead of the server.
3 — Every file has the same problem in it, because every file was generated from the same wrong assumption.

How small is it, honestly?

This is the question people skip, and it changes the answer more than the other three. An app rebuildable in days is a different decision from one rebuildable in months, because the cost of being wrong is different. A small app with a bad schema is often worth redoing purely because redoing it is cheap. A large app with the same bad schema almost never is. Count the screens a user can reach and the tables the app writes to.

0 — Dozens of screens, many tables, integrations with outside services, real customers depending on it.
1 — A substantial app, but one person could hold the whole thing in their head.
2 — Under ten screens and a handful of tables.
3 — A few screens, one or two tables, no payments, no integrations.

Reading the total

Question 4 is weighted the same as the others on purpose. Size is the axis most people leave out, and it flips more decisions than any single technical finding.

Score 0–3Fix it.: The structure is broadly sound and the problems have addresses. Rebuilding at this score means throwing away working decisions to solve something a targeted piece of work would solve.
Score 4–7Partial rebuild.: The most common band and the most commonly mis-handled one. Something specific is wrong, usually the data layer, and the rest of the app is fine. Replace the part that is wrong.
Score 8–12A rebuild is worth pricing.: Get it priced against a fix by the same person, in writing, with both numbers visible. A rebuild that is genuinely cheaper survives that comparison easily.

A number out of twelve is not a verdict. It tells you which conversation to have and what evidence to ask for. Anyone who reaches the opposite conclusion should be able to say which question they scored differently and why.

Signals, side by side

Most apps show signals in more than one column. That is normal, and it is usually the argument for a partial rebuild rather than for either extreme.

Signals that point toward fixing, rebuilding, or leaving an AI-built app alone
What you are looking at	Points to fixing	Points to rebuilding	Points to leaving it alone
The schema	Tables describe the product. New features mostly mean new columns.	The core entity has no table. Features are implemented by working around the schema.	The schema is odd but nothing new is being built on it.
Where bugs appear	Repeatedly in the same few modules.	Everywhere, from one repeated mistake.	Rarely, and users have not reported one in months.
Size	Large enough that redoing it would take months.	Small enough to redo in days.	Any size, as long as it is stable and untouched.
Dead code	Some, and it can be identified and deleted.	So much that nobody can identify the live path.	Irrelevant. Nobody is editing it.
Data sensitivity	Real user data, so the fixes need to happen either way.	Real user data and the access rules cannot be retrofitted onto the current model.	No personal data, no payments, no credentials worth stealing.
Rate of change	You ship changes weekly and they are getting harder.	You have stopped shipping because you are afraid to touch it.	You have not changed it this year and do not plan to.
Who understands it	Someone can explain the main flows, even if not every file.	Nobody can explain how a request becomes a database write.	Nobody understands it and nobody needs to.

The third option nobody sells you: do nothing

There is no vendor anywhere with a financial reason to tell you this, so it gets left out of every version of this article: a large number of AI-built apps should be left exactly as they are.

Three conditions, and all three have to hold.

It works. Users can do the thing the app exists for. Failures are rare enough that you are not tracking them.
You are not editing it. Bad structure costs you when you change things. Code nobody touches charges no interest. An internal tool that has run unmodified for a year is not accruing a problem.
It holds nothing worth stealing. No personal data, no payment details, no credentials, no access to a system that does have those things.

If all three hold, the correct amount of engineering is zero. Not zero for now. Zero. Ugly code that runs quietly and stores nothing sensitive is not a liability, it is just software you do not like the look of, and you are not obliged to spend money on that.

The third condition is the one that fails most often, and it fails silently. An app that collects email addresses holds personal data. An app with a login holds credentials. An app that calls a paid API on behalf of anonymous visitors can generate a bill. If any of those apply, the app is no longer inert, and the honest recommendation shifts to reading the code even if you then change nothing.

Doing nothing is a decision with a review date, not a permanent state. The moment you start editing the app again, or the moment it starts holding real user data, rerun the four questions. The score will have moved.

The partial rebuild, which is usually the right answer

The framing of fix-versus-rebuild is wrong in most cases, because the problem is rarely distributed evenly. It sits in one layer. The usual pattern in AI-built applications is an interface that is genuinely good and a data layer underneath it that was invented one feature at a time.

Keep the interface. It is not just screens, it is a record of product decisions you made by watching real people use the thing: which fields they fill in, which screens they never open, what the error messages needed to say. Recreating that knowledge is expensive, and it is the part a rebuild quietly throws away.

Then replace one subsystem behind it. Usually that means designing the schema you should have had, writing a migration for the data you already hold, and moving the frontend onto it. Sometimes it means replacing authentication, or payments, or the file-upload path, and leaving everything else untouched.

What this looks like in practice

The new data layer runs alongside the old one until the migration is verified, so there is always a working version of the app.
Each screen moves over individually. If one breaks, you know exactly what broke it.
The work has a finish line you can see, which a full rebuild does not until it is nearly over.
You can stop halfway and still be better off, which is the property that makes this worth doing.

A full rebuild has none of those properties. It is one long stretch with no working software in the middle, and it is the option most likely to end with two half-finished applications.

“The AI wrote it, so it has to be rewritten”

This argument is common and it does not hold up. Reviewed AI-assisted code is what most professional teams ship in 2026, including ours. The question worth asking is not what typed the code. It is whether anyone read it afterwards, and whether the failures that AI assistance actually produces were looked for specifically.

That distinction matters because the defects are not randomly distributed. The research points at structure rather than syntax, which is the same thing this whole decision turns on.

AI-assisted developers produced three to four times more code and ten times more security findings. Privilege-escalation paths rose 322% and architectural design flaws 153%, while syntax errors fell 76% and logic bugs fell 60%.

Source: ApiiroLimitations: Apiiro sells application security software. The finding is also in tension with METR's research, which measured experienced developers working more slowly with AI assistance. Treat the direction as informative and the magnitudes as vendor-reported.

45% of AI-generated code samples failed security testing, introducing OWASP Top 10 vulnerabilities. Syntactic correctness improved sharply from 2023 to 2025 while security pass rates stayed flat at 45–55%.

Source: Veracode, GenAI Code Security ReportLimitations: Veracode sells application security testing, so it has a commercial interest in the finding. The study covered 80 coding tasks across 100+ models. Failure rates varied by language: Java 72%, C# 45%, JavaScript 43%, Python 38%.

Across 2.23 million generated code samples, 19.7% referenced a package that does not exist, producing 205,474 unique fabricated package names. 43% of hallucinations repeat across runs.

Source: USENIX Security SymposiumLimitations: Peer-reviewed. The repeatability of hallucinated names is what makes dependency-registration attacks ('slopsquatting') practical.

Read together, those findings describe a specific shape of problem. The code compiles and reads well. What goes wrong sits below the surface: how permissions are arranged, what the schema assumes, which dependencies are real. None of that is fixed by having a human retype the same design, which is what a rebuild often amounts to when nobody has worked out what was structurally wrong first.

The Veracode finding is worth holding onto for a different reason. Security pass rates stayed flat while syntactic quality improved sharply. A rebuild by the same process, with the same unstated assumptions, produces the same class of gap. What changes the outcome is specifying the things nobody specified the first time, not regenerating the code.

The dependency finding has one practical consequence for this decision. If your app imports packages that do not exist upstream, that is checkable in minutes and fixable without touching anything else. It is not a rebuild argument. It is a Tuesday.

Fix or rebuild — common questions

Should I rebuild because a developer told me the code is bad?

Not on that basis alone, because 'the code is bad' is a judgment, not a finding. Ask which specific file or table is the problem, what breaks because of it, and what fixing just that part would cost compared to replacing everything. An engineer who has read your code can answer all three in a few minutes. One who has skimmed it and reached for the word 'legacy' cannot, and that difference is the entire signal you are looking for.

Can I rebuild it with AI again and get a better result?

Sometimes, and it depends entirely on whether you now know things you did not know the first time. The first build failed partly because you were still discovering what the product was, so you could not specify the parts that matter: what the data actually looks like, who is allowed to read which records, what happens when a payment fails. If you can write those down now, a second attempt starts from a much better brief. If the only change is that you will try harder, the second version fails the same way as the first, because effort was never the missing input.

How do I get a rebuild quote I can trust?

Ask for the fix quote and the rebuild quote from the same person, at the same time, in writing. Vendors are not usually dishonest about this, but rebuilds are larger, longer, and easier to scope than repairs, so the incentive points one way for everybody in this market including us. Seeing both numbers next to each other makes the comparison yours rather than theirs.

If I rebuild, do I lose everything I have?

No, and treating the existing app as disposable is how rebuilds go wrong. The interface encodes hundreds of product decisions you made by looking at the thing and reacting: which fields users actually fill in, which screens they never visit, what the empty states needed to say. That knowledge is expensive to recreate and cheap to keep. Keep the screens and the copy, and rebuild what sits behind them.

What if the app works fine and I just do not trust it?

Then the useful next step is a read of the code, not a decision about its future. Distrust is usually about specific unknowns, most often whether one customer can read another customer's data and whether anything is exposed that should not be. Those are checkable in hours. Deciding to rebuild in order to make an uneasy feeling go away is the most expensive available form of reassurance.

Want the reasoning, not just a verdict?

Send us what you built and what is worrying you. If the honest answer is that your app should be left alone, that is what we will tell you.

Request a Codebase Review See pricing