Fix, Refactor or Rebuild? A Decision Matrix for AI-Built Apps

The most expensive mistake is choosing the wrong path

When an AI-built application is broken or stuck, there are three possible responses: fix the specific fault, refactor the codebase to correct structural problems while preserving the working parts, or rebuild from scratch. Each path has a different cost, a different risk profile, and a different appropriate use case.

Choosing the wrong one is more costly than the choice itself suggests. Paying to fix an application that needs a refactor means paying to fix it again in three months when the next fault emerges from the same structural root cause. Paying to refactor an application that needs a rebuild means spending money on a codebase that cannot be made safe. Paying to rebuild an application that only needs a fix means discarding working components and delaying your launch without reason.

The decision is not obvious from the outside. A non-technical founder looking at a broken Lovable or Bolt.new application cannot tell, without an engineering review, whether the issue is a three-line configuration error or a fundamental architectural problem. What they can do is answer a series of questions about the application that make the distinction clear.

Defining the three paths

Fix

A fix addresses a specific, bounded fault without changing the application's structure. Examples: correcting a missing environment variable, updating OAuth redirect URIs for the production domain, enabling live mode in Stripe, adding a production domain to Supabase's allowed redirect list. A fix is appropriate when the application is fundamentally sound and the problem is a configuration or deployment issue rather than an architectural one.

Fixes are fast and cheap. They are also easily scoped: a fixed-price quote for a fix is reliable because the work is bounded. The risk of a fix on an unsound codebase is that it resolves the visible symptom without addressing the underlying problem — producing the illusion of resolution while leaving the root cause in place.

Refactor

A refactor rewrites the internal structure of the application while preserving its external behaviour. The UI that users see remains the same; the code that produces it is rebuilt to a safer, more maintainable standard. Refactoring is appropriate when the application has correct functionality in some areas but unsafe or unmaintainable implementation, and when the investment in the existing frontend and user experience is worth preserving.

Refactors are more expensive than fixes and take longer. They require a clear technical plan — a refactor without a plan accumulates new structural debt as fast as it clears the old kind. The benefit is that a well-executed refactor produces a codebase that can be extended safely and maintained without an AI tool in the loop on every change.

Rebuild

A rebuild starts from scratch. The existing codebase is used as reference for the requirements — what the application needs to do — rather than as the starting point for the code. Rebuild is appropriate when the existing codebase has accumulated so much circular-fix debt that targeted remediation would cost more than a clean implementation, or when the architecture is fundamentally incompatible with the production requirements.

Rebuilds are expensive and time-consuming when done manually. When an AI tool is used as a construction aid under human engineering oversight — rather than as the autonomous author — the cost is substantially lower than a traditional software rebuild. The output is a codebase that is structured correctly from the first commit, with the AI accelerating implementation while the engineer controls the architecture.

The decision matrix: nine questions

Answer each question as honestly as you can about your current application. The scoring at the end indicates the correct path.

Security questions

1. Are there API keys, database credentials, or secrets in client-accessible code or in the public repository? Yes = 3 points. No = 0 points. (This is the highest-severity issue. Exposed credentials cannot be safely left in place — they must be rotated immediately regardless of which path you choose.)
2. Has Supabase RLS been reviewed by a human engineer? Not reviewed = 2 points. Reviewed and found permissive = 2 points. Reviewed and confirmed correct = 0 points.
3. Does the application handle personal data, financial data, or health data without a documented UK GDPR lawful basis? Yes = 2 points. No = 0 points.

Architecture questions

4. Has the application been through more than five rounds of AI-prompted fixes for the same category of error without resolution? Yes = 3 points. No = 0 points. (This is the clearest indicator of circular-fix debt.)
5. When the AI fixes one error, does it introduce a new error in a different part of the application? Consistently = 3 points. Sometimes = 1 point. Rarely or never = 0 points.
6. Is the codebase above approximately 5,000 lines of code? Yes = 1 point. No = 0 points.

Deployment questions

7. Does the application fail to build at all on the target hosting platform? Yes = 2 points. No = 0 points.
8. Has the application ever successfully deployed to the production environment? Never deployed successfully = 1 point. Was working and has regressed = 0 points.

Commercial context

9. Are there real users on the application, or is launch imminent? Users present with active data = add 1 point to any score above 5 (higher urgency). Launching within 7 days = same. No users yet = 0 points.

Scoring

Score	Recommended path	What it means
0 to 3	Fix	The application has bounded, specific problems. A targeted fix is appropriate. The issues can likely be resolved without a senior engineering review, using the self-diagnosis checklist in our companion article.
4 to 7	Diagnostic Audit, then fix or refactor	There are too many compounding issues for a self-directed fix to be reliable. A professional audit is the correct next step — it will tell you whether the issues are fixable with targeted remediation or whether the structure of the codebase requires a refactor.
8 to 12	Refactor (likely), rebuild (possible)	The application has significant structural problems. A refactor is probably the correct path, but a Diagnostic Audit is required to confirm — rebuilds are only necessary when the architecture is fundamentally incompatible with the production requirements, which requires engineering review to assess.
13+	Diagnostic Audit required — rebuild likely	The combination of security exposure, circular-fix debt, and architectural issues suggests the codebase has reached a state where further patching is unlikely to be cost-effective. A Diagnostic Audit will confirm this and scope the rebuild.

The cases where a rebuild is always correct

Regardless of the score, certain conditions make a rebuild the correct answer. These are not about the degree of the problem but about its type.

• The application has a Supabase service role key in client-accessible code. This key bypasses all RLS policies and provides full database access. It cannot be safely left in place and cannot be patched out of a deployed application without a complete credential rotation and rebuild of the environment variable architecture.
• The database schema has no coherent design — tables created by AI prompting without a plan, with no foreign key relationships, inconsistent naming, and no audit trail of what the schema is intended to represent. A refactor cannot make an incoherent data model coherent; it requires a deliberate redesign.
• The authentication implementation stores user passwords or credentials in a format the engineer cannot verify as secure. Any uncertainty about password storage format is sufficient grounds for a rebuild of the auth layer.
• The application has been through more than ten rounds of circular AI fixing and the engineer conducting the review cannot trace a coherent flow through the codebase. At this point, the cost of understanding the existing code exceeds the cost of a clean implementation.

What a proper diagnostic tells you that the matrix cannot

The decision matrix above gives you a starting position. It cannot tell you whether a specific Supabase RLS misconfiguration is trivially correctable or structurally embedded. It cannot tell you whether the circular-fix debt in your codebase has produced regressions in working components that are not yet visible. It cannot tell you the actual cost of a refactor versus a rebuild for your specific application.

A Diagnostic Audit answers those questions. It is a senior engineer reviewing the actual codebase — not a scanner, not an AI assessment of the AI's own work — and producing a written report with a specific recommendation and a scoped quote. The audit costs £495 and takes 3 to 5 working days. It is the correct step before committing to any remediation path on an application with a score above 3 on the matrix above.

The reason to do the audit before the fix is simple: a fix on an unmapped codebase is a guess. The audit makes it a plan.