Your AI-built app works. That is the problem. It runs bookings, billing or the customer portal well enough that paying users depend on it, and nobody wants to be the one who breaks it. Yet every new feature takes longer than the last, the person who built the first version with an AI tool has moved on or never wrote anything down, and your best engineers spend their week fixing bugs instead of building the roadmap.
So the question lands on your desk: refactor or rewrite, or replace part of it with something off the shelf? Each answer has loud advocates. Developers who inherited the code want to regenerate it from scratch with the AI tool. Finance prefers whatever looks cheapest this quarter. Vendors pitch their platform as the replacement. For most AI-built apps the real answer is none of the three in pure form: it is a deliberate mix, chosen module by module, with refactoring as the default.
The stakes are not abstract. In a McKinsey survey of CIOs, tech debt amounted to 20–40% of the value of the entire technology estate, and 10–20% of the budget meant for new products was diverted to servicing it. This guide gives you a practical framework to decide when to refactor, when rewriting a component is justified, how to stage that rewrite and how to make the call on evidence, without betting the business. The wider picture sits in our founder’s guide to AI-generated code in production.
TL;DR
Refactoring restructures existing code without changing what users see; rewriting replaces code with a new version that has to reproduce the same behaviour. For an AI-built app with active users, refactor the parts that still support the product’s requirements and rebuild a component only when evidence shows that a targeted change or supported upgrade cannot meet an essential requirement at acceptable cost and risk.
- Refactoring is the right default when the business logic is correct, the problems are concentrated in a few modules and a supported upgrade path exists: the product keeps earning while the code improves behind tests.
- A component rewrite is justified in four situations: the data and authorisation design cannot enforce required access boundaries without disproportionate rework, an unsupported technology blocks required updates and cannot be upgraded or contained, the core workflows have changed beyond the architecture, or a written comparison shows replacement carries lower total cost or risk.
- A staged rewrite, known as the strangler fig pattern, replaces one component at a time (often the data layer or login) while the rest of the app keeps running.
- The refactor or rewrite decision belongs on evidence: tests, dependency analysis and a findings report from a review that is independent of whoever would be paid to do the work.
Refactor, rewrite or replace: what is the difference?
Refactoring, rewriting and replacing are three different answers to a codebase that has become hard to change. Refactoring changes the structure of the code but not its behaviour: Martin Fowler’s Definition of Refactoring describes it as a change to the internal structure of software that makes it easier to understand and cheaper to modify, without changing its observable behaviour.
A rewrite replaces code with a new version that must reproduce what the old version did; “rebuild” and “starting from scratch” describe the same decision. Replacing swaps a commodity module, such as login, payments, email or search, for a managed service or an off-the-shelf product.
| Option | What changes | What stays | Risk | Typical trigger |
|---|---|---|---|---|
| Refactor | Structure, naming, duplication, tests | Behaviour, data, users, integrations | Low when changes are small and covered by tests | Code works but is hard to change |
| Rewrite | One component, or in rare cases the whole codebase | The data (after migration) and the users | High: hidden fixes can be lost and timelines slip | A component cannot meet an essential requirement through targeted change |
| Replace | One commodity module becomes a managed service | Everything around that module | Medium: integration and data transfer | A standard function the product does not need to own |
Our recommendation: start from refactor and justify every step away from it, one component at a time.
Why a rewrite looks cheaper with AI tools, and usually is not
A rewrite of an AI-built app looks cheap because AI coding tools can generate a new version of the code in days. The code, however, is the cheapest part of the product to reproduce. What a rewrite throws away is everything the product has learned since launch: edge cases fixed after user complaints, data already stored in a particular shape, integrations and their keys, and behaviour that customers now rely on.
The classic warning against rewrites dates from April 2000. In Things You Should Never Do, Part I, Joel Spolsky described how Netscape decided to rewrite its browser from scratch and then went almost three years without shipping a major new release. Old code often looks messy partly because it contains years of bug fixes.
Many AI-built apps add a second risk: they reach production without automated tests or a written specification, so nobody can show that a regenerated version does everything the current one does. The lower-cost appearance of a regenerated app holds only while the product has few users, little stored personal data and few integrations.
Six signals that decide refactor or rewrite
Code should be refactored when it does the right thing but has become hard to change; a component should be rewritten only when it cannot do what the product needs next after feasible fixes have been assessed. Six signals show which side a part of an AI-built app is on, and a founder can check most of them without reading code. Read the table per component, not for the app as a whole.
| Signal | Points to refactor when… | Points to investigating a rewrite when… | How a founder can check it |
|---|---|---|---|
| 1. Business logic | The rules match how the business works today | The rules are wrong for the current business model | Walk through the three most important user flows with the person who owns them |
| 2. Data model | Access boundaries can be enforced through schema, policy or authorisation changes | Required access boundaries cannot be enforced without reworking most of the data layer | Ask the developer how the app guarantees that customer A never sees customer B’s data |
| 3. Spread of problems | Findings are concentrated in a few modules | The same bug class appears across the whole codebase | Count which modules the last ten bug reports touched |
| 4. Stack | Framework and runtime have a supported upgrade path | A key technology is unsupported and cannot be upgraded or contained | Compare versions with the vendor’s published support dates |
| 5. Knowledge | Someone can explain how the code works, or tests and a specification exist | Nobody can explain it and the product has moved far from the original intent | Ask the developer to explain one module in 15 minutes without opening the AI tool |
| 6. Change cost | Fixes stay local | Each fix regularly breaks something else | For four weeks, track how often a fix causes a new bug and how much team time goes to fixes instead of features |
Treat the six signals as prompts for investigation, not a numerical vote. If problems are local and the existing architecture can support the next release, prioritise tests and targeted refactoring. If a component cannot meet an essential requirement after feasible fixes and upgrades are assessed, scope a staged replacement of that component. Compare cost, customer disruption, security impact and rollback options before approving the work.
Signal 4 needs care. The Node.js Release Working Group ended support for Node.js 18 on 30 April 2025, so an app on that runtime no longer receives its security patches. The first answer to an end-of-life runtime is an upgrade plan for the runtime and its dependencies; a rewrite enters the discussion only when that upgrade is not feasible. Signal 5 also cuts both ways: missing tests make refactoring slower, but they make a rewrite riskier, because there is nothing to check the new version against. The structural causes behind signal 6 are covered in our guide to AI technical debt.
Not sure which column your product sits in?
Most of the six signals can only be read from inside the code. An AI-built product review checks engineering and security together and explains the findings in plain English, so you can see which parts to keep, which to refactor and which, if any, to rewrite, before you commit budget to either.
Why is refactoring the default for most AI-built apps?
Refactoring is the default for most AI-built apps because the product stays live and earning while the code improves. When each change is kept small and checked by tests before the next one starts, the hidden fixes inside the current code survive and any mistake can be rolled back. The team can also keep shipping features in parallel, which a full rewrite usually blocks for months.
Refactoring legacy code an AI wrote: tests first
Refactoring legacy code an AI wrote starts with characterisation tests: automated tests that record what the code does today, correct or not, before anyone changes it. Michael Feathers introduced the term in Working Effectively with Legacy Code (2004). With those tests in place, a regression (something that used to work and now does not) shows up when it happens, instead of in a customer email.
A practical order: cover the three flows that earn money (sign-up, the core action, payment), then refactor the module with the most bug reports, then repeat. Each round ends with the tests passing and the product still deployed.
Is AI good at refactoring code?
AI coding tools are useful for repetitive, well-scoped refactoring work: renaming, extracting duplicated code into one function and writing first drafts of tests. They are weaker at changes that need knowledge of the whole system or of the business rules, such as changing how customer data is separated. AI-assisted refactoring is safe when a person reviews every change and the tests run on every change.
When is a rewrite the right call?
A rewrite is justified when an essential product requirement cannot be met safely or economically through targeted changes. Evaluate the decision for each component, not automatically for the whole app.
- The data and authorisation design cannot enforce required access boundaries without disproportionate rework, after viable schema and policy changes have been assessed. If customer data is exposed today, fix that access path immediately, whatever the longer-term decision.
- An unsupported technology prevents required security or product updates, and a supported upgrade or contained replacement is not feasible.
- Core workflows, deployment constraints or business rules have changed so substantially that the existing architecture no longer fits, for example a pivot to a new customer type or an on-premise requirement.
- A documented comparison of remediation, re-architecture and staged replacement shows that replacement has lower total cost or operational risk over the planning horizon.
The GDPR is relevant to the first situation: Article 25 asks for data protection by design, meaning appropriate technical measures built into how personal data is processed. The regulation sets the outcome, not the method, so it does not by itself require a rewrite.
Before starting a rewrite, document expected behaviour, acceptance criteria, migration and rollback plans. Those are safeguards for the chosen approach, not independent reasons to rewrite.
The middle path: rewrite one component at a time
The middle path between refactoring and a full rewrite is to replace one component at a time while the current app keeps running. Martin Fowler named this the strangler fig pattern in 2004 and updated the essay in 2024: new parts are built around the old system and take over one route or feature at a time, until the old part can be switched off. Users keep working throughout, and each step can be checked and reversed.
Start where the signals are worst and the risk can be contained, which in AI-built apps is often the data layer or authentication. Replace commodity modules with a managed service instead of rewriting them. A typical case: a subscription booking product where invoices, login and the customer dashboard work, but customer separation relies on fragile application logic. A sensible plan redesigns the data layer and its access rules, moves login to a managed identity service and keeps the invoices and dashboard, refactoring them as they are reconnected.
The staged route needs someone who keeps old and new parts consistent for the whole transition. When the team does not have that capacity, product engineering support can run the transition while the founder’s team keeps the product moving.
What does a rewrite cost beyond the code?
A rewrite of an AI-built app costs more than the new code, because several other pieces of work come with it. Table 3 lists the hidden cost categories to put in any estimate, next to how they compare with refactoring in place.
| Cost category | Refactor in place | Staged rewrite of a component |
|---|---|---|
| Data migration | Usually none, or small schema changes | Records move to a new model: rehearsal, verification, cutover |
| Parallel running | None | Old and new components run side by side during the transition |
| Feature work | Continues alongside the refactor | Slows or pauses for the parts being replaced |
| Re-testing | Flows touched by each change | Every flow that depends on the replaced component |
| Review before relaunch | Optional, per release | Needed for the new component before it takes live traffic |
Data migration. Before moving personal data to a new model, rehearse the migration in an appropriately secured test environment, using synthetic or minimised data where feasible. Verify record counts, ownership and access rules; plan backups, rollback and a controlled production cutover. GDPR Articles 5(1)(f), 25 and 32 provide the relevant data-protection principles, but they do not require a full rewrite or a specific migration architecture.
Parallel running. Running old and new components in parallel can increase infrastructure, monitoring and support costs during the transition. The increase depends on how much of the system runs twice, how long the overlap lasts and whether managed services can be shared, so include that overlap explicitly in the estimate.
Review before relaunch. The rebuilt component needs its own go or not-yet decision, covered in our guide to the production readiness review. The cost of the review itself is set out in our guide to AI code audit cost.
Who should make the refactor or rewrite call?
The founder makes the refactor or rewrite call, but on a findings report, not on a feeling after a bad week. Two incentives are worth naming calmly: the team that wrote the code may defend it, and a supplier who would be paid for the rewrite has a reason to recommend one. Evidence from a review that is independent of whoever does the work removes both; what such a review covers is explained in our guide to the AI code audit.
Record the decision as well. For organisations that run an ISO/IEC 27001:2022 information security management system, Annex A control 8.32 on change management is the relevant framework guidance: significant changes are planned, assessed and approved before they go live. Before deciding, ask three questions: which signals point to a rewrite, what breaks for users if we wait three months, and what is the smallest part we could replace first.
How Sunbytes helps decide what to keep, refactor or rebuild
A refactor or rewrite decision needs more than a code-quality score. It needs evidence of which user flows, dependencies and security controls work today, and which changes would put them at risk.
The AI-built product review from Sunbytes examines the agreed code, security, critical workflows and deployment setup, then provides evidence-backed findings, prioritised recommendations and a plain-English walkthrough. The results help your team weigh targeted refactoring, a staged component replacement or a separately scoped product engineering project. Remediation and re-checks can be discussed as follow-up work rather than assumed to be included.
Sunbytes is a Dutch-founded company, headquartered in Utrecht with a delivery hub in Vietnam since 2011. Over 15+ years, Sunbytes has delivered 300+ projects for clients in 20 countries and is ISO 27001 certified. Start with an AI-built product review to clarify the evidence and scope before committing to a rewrite.
