Fix It or Rebuild It? An Honest Framework for AI Prototypes

Developers tend to recommend rebuilds, and it helps to understand why before taking the advice. Reading someone else’s code is harder than writing new code. That has been true for decades, and AI-generated code sharpens the effect: it is verbose, it repeats itself, and nobody on the team wrote it, so nobody can explain it. A rebuild quote also feels cleaner to produce. “Six weeks to rebuild” sounds more certain than “two to four weeks to repair, depending on what we find.”

The trouble is what a full rebuild throws away. A working prototype is not just code. It is a record of decisions: what the product actually does, which edge cases came up in real use, what users clicked and what they ignored. Rebuilding from scratch means re-making every one of those decisions, and some of them will be re-made wrong. Rebuild timelines also slip in a familiar way: the first 80 percent goes quickly, then the details that the old version already handled start surfacing one at a time.

So the honest starting position is that the existing code is innocent until the evidence says otherwise. Whether an AI codebase is salvageable is something a review can show, not something to assume from how the code looks on first scroll.

The quality problems in AI-generated code cluster in predictable places, and so do the strengths. That pattern is what makes a keep-or-rewrite decision possible at all.

The parts that tend to hold up are the local ones. Individual functions usually do what they say. Standard framework patterns, form handling, screens that read and display data: AI coding tools were trained on enormous amounts of exactly this material, and their output for common tasks is often fine. In review we regularly find whole sections, especially interface code, that need nothing more than light cleanup.

The parts that tend not to hold up are the ones that cut across the whole application. Security is the usual headline: credentials pasted into source files, authorization that exists in the interface but not on the server, inputs that reach the database unvalidated. Beyond security, the recurring problems are structural. The same logic gets duplicated in several places, so one fix has to be applied three times. Error handling covers the happy path and little else. The data model sometimes drifts, with the same concept stored two different ways in two different features.

None of this is a verdict on its own. It is a map of where to look. A prototype can carry every one of these flaws and still be a better foundation than a blank repository.

When we draw the keep, fix, rebuild line for a codebase, four questions do most of the work.

First, the data model. This is the foundation everything else sits on, and it is the hardest thing to change later. If the schema is coherent, if a customer is one thing stored one way and the relationships between records make sense, that argues strongly for keeping the base and repairing around it. If the data model is contradictory or missing, the rebuild case gets serious, because every feature built on a broken model inherits the break.

Second, the security surface. Count the exposures and weigh their severity. Hardcoded keys, missing server-side checks, and unvalidated inputs sound alarming, and they are, but they are also typically repairable in place. A long list of shallow exposures is a fix job. The security findings rarely force a rebuild by themselves; what matters is whether fixing them means restructuring the application or just correcting it.

Third, change frequency. Ask which parts of the app the business will touch often. A billing flow you plan to iterate on weekly needs code a developer can change safely, so its quality bar is high. A settings page that will sit untouched for a year can be mediocre and nobody will suffer. Spending rebuild money on code that just sits there and runs is a common way to waste a budget.

Fourth, the team. Who maintains this code next year? If the plan is to hire a developer, the framework and language the AI chose start to matter, because they define the hiring pool. If the plan is a support partner, ask them what they can confidently maintain. Code nobody on the future team can work on is a liability whatever its quality.

Run all four questions and a shape emerges. In our experience the answer is rarely all-keep or all-rebuild. It is usually a split: keep this, fix that, rebuild this one part properly.

Sometimes rebuilding an AI app from scratch really is the cheaper path, and the useful thing is that the signals show up early, in the first serious review, not after months of failed repairs.

The signals we treat as rebuild evidence: a data model that contradicts itself at the core, so that repairs would mean migrating live data anyway. A framework or architecture choice that fights the product’s direction, like a prototype built as a single page app when the business needs content that search engines can index. Duplication so pervasive that any change costs three or four times what it should, forever. Or an app so entangled with the tool that generated it that nobody can run it anywhere else.

Even then, rebuild rarely means everything. A common outcome is a partial rebuild: keep the front end users already like, rebuild the server side under it, or the reverse. The prototype keeps its job as the specification, which is a real job. Building a product whose behavior you can already see is considerably faster than building from a document, and it is one reason a rebuild informed by a working prototype costs less than the first build would have.

What a founder should watch for is timing. A trustworthy rebuild recommendation arrives with specifics: which of these conditions the codebase meets, with examples from the code. A rebuild recommendation that arrives in the first hour, without evidence, is usually the reading-is-harder-than-writing instinct talking.

Whatever the answer turns out to be, it belongs in writing before anyone starts billing for the work. The document does not need to be long. It needs to list the areas of the application, say keep, fix, or rebuild for each one, and give the reason and a rough effort estimate per line.

That document does two jobs. It keeps the project from drifting, because a repair engagement that quietly turns into a rewrite is a known failure mode, and a written split makes the drift visible the week it starts. It also keeps the vendor honest. A firm that will not put the split on paper, or whose answer for every area is rebuild, is telling you something about its incentives. Rebuilds bill more hours.

It is fair to expect the reasoning, not just the conclusions. “Rebuild the API layer because authorization has to be restructured, keep the interface because it needs only cleanup” is a sentence a founder can evaluate and challenge. “The code is bad” is not.

This is the shape of our Production Readiness Assessment. We review the codebase, run the four questions, and the assessment draws the keep, fix, rebuild line for your specific code, in plain English, before you commit to either path. If the honest answer is that most of your prototype is worth keeping, the report says so. If part of it should be rebuilt, the report says that too, with the evidence attached, and the decision stays where it belongs: with you.