Fix or Rebuild Your AI-Built App? A Founder's Decision Guide
Fix the existing app when the problem has a clear boundary and the repair can be tested. Consider a rebuild when the structure blocks the changes the product needs and a smaller intervention cannot remove that blocker at acceptable cost and risk. The fact that AI wrote the code is not enough evidence either way.
TL;DR
- Start the review with the next feature you need, a reproducible failure and the behaviour that must stay unchanged.
- Separate urgency from scope. A serious failure may have a targeted fix; repeated breakage needs investigation, not an automatic rewrite.
- When the scope is unclear, test one small feature in a non-production environment and record which parts it touches.
- Compare repair and rebuild proposals against the same outcome, including testing, data migration, deployment and handover.
- Require evidence for each keep, fix or replace decision, plus an explanation of what the smaller option leaves unresolved.
Start with the next feature you can't ship
Write down the change that matters to the business. “Let customers cancel an order before it is dispatched” is something a developer can investigate. “Make the code production-ready” leaves the scope undefined.
For the last failed attempt, record the version you started from, what you changed, what you expected and what actually broke. Include a reproducible example using test data. Also name the behaviour that must stay the same, such as existing orders keeping their original prices.
This gives a review a concrete question: what prevents this change, and how much of the application must change to support it?
Fix, refactor, replace a component or rebuild?
A fix corrects a specific failure. A refactor changes the internal structure while preserving external behaviour, as defined in Martin Fowler's refactoring guide. It can prepare the code for a feature without replacing the whole application.
Replacing a component goes further. For example, you might replace the order-processing logic while retaining the storefront and customer accounts. A full rebuild replaces the application's implementation across the agreed scope. It does not automatically require new screens, a new product concept or replacing every external service.
Ask a contractor to name which of these they are proposing. “Clean up the AI code” is not a scope you can compare or accept.
Check what the symptom actually tells you
The checks below are starting points for a review, not diagnoses of your app. The last column applies only when the proposed cause has been demonstrated.
| What you notice | What to check | What the evidence could justify |
|---|---|---|
| A password-reset link works in preview but sends users to localhost after launch. | For a Supabase app, check Site URL and the allowed redirect URLs against the production address. See Supabase's redirect documentation. | A configuration fix if the wrong destination explains the failure. This symptom alone says nothing about the rest of the app. |
| One dashboard gets slower as the database grows. | Identify the slow request, then inspect its database query plan using representative data. Supabase documents query-plan and index checks; adding indexes blindly can also make writes slower. | A query, pagination or index change if the measurements support it. A slow screen does not establish that the platform must be replaced. |
| One successful payment creates two orders in the app. | Compare payment records with webhook deliveries and application logs. Stripe can deliver the same event more than once. Check whether processing it again creates another order. | A targeted event-handling fix if duplicate processing is confirmed. Two orders do not, by themselves, prove that the customer was charged twice. |
| Changing a pricing rule fixes checkout but leaves invoices wrong. | Trace where the rule is calculated. Is it duplicated, or do checkout and invoicing deliberately use different rules? Establish the intended behaviour before changing code. | A focused refactor if one business rule has drifted across multiple implementations. Keep legitimate differences, such as historical invoice prices. |
| Every new feature breaks something outside the feature being changed. | Take a recent example and map what changed, what failed and which shared code or data connects them. Test whether the problem can be isolated. | Replacement of one shared component, or a wider rebuild if the same structural constraint spans the product. The repeated symptom is a reason to investigate, not a verdict. |
| The builder cannot support a workflow the business now requires. | Name the exact missing capability and verify the limit. Test whether an integration or a separately built component can cover it without replacing the working parts. | Replacement of the constrained part, or a platform migration when the limit is real and the smaller option is unsuitable. |
A small repair can address a serious failure. A duplicate order may affect fulfilment and money, but severity and repair scope are different questions. Handle any active harm first; don't leave it running while debating a replacement.
Test the recommendation with one real feature
When the review is inconclusive, agree a bounded investigation before approving a full implementation. Choose a small version of the next feature, define what the investigation will answer and cap its scope. Use a non-production environment with test data, not customers as the experiment.
For example, suppose a shop needs customers to cancel an order before dispatch. The existing app records order status differently in the customer screen, admin screen and fulfilment integration.
First, write the acceptance conditions: an eligible cancellation changes all three views consistently; a dispatched order cannot be cancelled; repeating the request does not repeat its effects. Check the current behaviour before making changes so that an old defect is not mistaken for a new one.
Then ask the developer to attempt the smallest coherent change and report what it touched. Two outcomes would support different decisions:
- If one shared cancellation rule can replace the conflicting copies while the other flows remain correct, that supports a focused refactor or component replacement.
- If each route writes incompatible order states and isolating cancellation requires changing every workflow that creates or updates orders, there is evidence for a broader redesign. It still does not explain why the storefront must be rewritten.
The useful result is a tested boundary and a record of the remaining uncertainty. A failed attempt by one developer is not proof that no smaller solution exists. Ask what was tried, what made it fail and what evidence would change the recommendation.
When is a full rebuild worth considering?
A full rebuild deserves a serious proposal when the required changes cross the application's core and the review cannot identify a smaller, workable boundary. That might mean a central data model that cannot represent the required workflow, or a verified platform limit that affects the product's essential functions. The proposal should explain why local changes would leave the blocker in place.
The size and live usage of the application matter too. Microsoft's guidance on incremental replacement describes keeping the old application running while parts are replaced, but also notes that this approach may be unsuitable for a small system that is straightforward to replace entirely. Maintaining two implementations and the connections between them is work in its own right.
Separate how much you replace from how you switch over. A broad rebuild may still be rolled out in stages. A component replacement may still need a difficult data migration. “We'll keep the old app running” is incomplete without an answer to where new records go and how both versions stay consistent.
For live users, require a plan for migrating records, accounts and integrations. Ask how rollback handles records created after the switch. Restoring yesterday's code does not answer what happens to today's data. Shared data and coexistence are explicit concerns in Microsoft's migration pattern.
Do not approve a rebuild merely because the new code will be cleaner. Fowler's discussion of application replacement makes the underlying risk clear: without changing the way software is developed, the replacement can accumulate the same problems. Ask which tests, review steps and deployment checks will be different this time.
What should a useful audit hand back?
Ask for a written decision you could take to another developer. It should contain:
- The blocker and evidence. The requirement it prevents, a reproducible failure and the relevant code, configuration or logs. “Bad architecture” is a conclusion to explain, not evidence.
- A decision for each affected area. Keep, fix, refactor or replace, with a reason. Include working areas that do not need attention.
- An alternative and why it was rejected. What a smaller intervention would achieve, what it would leave unresolved and why that matters for the next feature.
- Comparable scope and estimates. Which existing behaviour survives, which new behaviour is included, and whether testing, migration, deployment and handover are inside the price range and timeline. Mark unknowns and the work needed to resolve them.
- Acceptance and exit conditions. What will demonstrate that the blocker is gone, how a failed rollout is handled, and which repository, accounts and operating instructions you receive.
An initial conversation can identify likely directions and missing evidence. It is not equivalent to an exhaustive security assessment, load test or migration rehearsal. The reviewer should distinguish what they inspected from what they inferred.
Compare proposals against the same outcome. A rebuild quote that only recreates the demo is not comparable with a refactor quote that includes existing users, historical records, integrations and support for the next feature.
Once the required work is clear, use our comparison of companies that work on AI-built and no-code prototypes to find providers to discuss that scope with. The comparison answers who does the work; the audit should establish what work your product needs.
When to leave the working app alone
If the app supports the current test of the product, a review has found no immediate issue requiring action, and the next feature is still speculative, avoid commissioning a rewrite purely to tidy the repository. Define the feature or validate the need first.
About Caemcore
Caemcore builds custom software for companies that outgrew off-the-shelf tools.
Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.
You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.
Built it on no-code or AI tools and it stopped changing? We start with an audit, not a quote. 30 minutes, free: what we keep, what we rebuild, what blocks launch, the range and the timeline.
You get that whether we work together or not.
FAQ
What should I send a developer before the review?
Send the next feature you need, steps to reproduce the failure, the version currently deployed and a list of connected services. Arrange access to the relevant code and configuration. Use test accounts and sample data where possible; do not paste production secrets or customer credentials into the brief.
Does having no automated tests mean my app needs a rewrite?
No. Missing tests do not establish which parts need replacing. Ask the developer to record the intended behaviour of important flows and add checks around the area being changed. Include testing in both proposals: a new codebase still needs evidence that it behaves correctly.
What should I do if two developers recommend different approaches?
Give both the same feature requirement and failure example. Ask each to identify the blocker, explain why the smaller option would or would not work, and list what their estimate includes. Where they disagree on a technical fact, commission a bounded test of that fact before choosing a larger project.
Should we stop adding features during a rebuild?
Decide this in the scope rather than assuming either a complete freeze or business as usual. Name who handles urgent fixes in the existing app and how approved changes reach the replacement. Require an impact review when a new feature changes the records or workflows being migrated.
Should I ask AI to rewrite the whole app before getting a review?
Treat that rewrite as an unverified candidate, not proof that replacement was necessary. Keep the known working version, isolate the proposed changes and test the same required behaviour. Ask for small, reviewable changes where possible. A successful demo alone does not settle the migration or maintenance questions.
Sources
- Martin Fowler, Refactoring. Checked 12 September 2026.
- Supabase, Redirect URLs. Checked 12 September 2026.
- Supabase, Query optimization. Checked 12 September 2026.
- Stripe, Webhooks. Checked 12 September 2026.
- Microsoft Azure Architecture Center, Strangler Fig pattern. Checked 12 September 2026.
- Martin Fowler, Strangler Fig. Checked 12 September 2026.
Manage cookie settings
