Signals for each path
| Signal | Points to rescue | Points to rebuild |
|---|---|---|
| Does it work for real users today? | Yes, with gaps | No, or only in the demo |
| Does the data model match how the business works? | Yes, or close | No — key relationships are missing or wrong |
| What happens when you change one thing? | The change stays where you made it | Something unrelated breaks |
| Where are the problems? | Missing production work: sign-in, data access, secrets, tests, monitoring | Throughout — the same logic copied in many places |
| Is the stack one you can hire for and host? | Yes | No, or tied to a tool you are leaving |
| How much of it would you keep? | Most of the screens and flows | Little beyond the idea |
Most AI-built apps land in the left column on some rows and the right on others. That is why the usual answer is a mix.
The middle path: keep what works, replace what fails
A rescue does not mean keeping every line, and a rebuild does not mean throwing away what you learned. In practice most teams keep the screens, flows and decisions the prototype got right, and replace the parts that fail — often the data layer and anything that touches money or personal data.
The safest way to replace parts is gradually: move one piece at a time while the rest keeps running. Martin Fowler describes this as the strangler fig approach — building new parts alongside the old and moving behaviour across in steps, so that “both investment and returns occur gradually and visibly” (martinfowler.com, updated 22 August 2024).
Why “just rewrite it” is riskier than it sounds
A rewrite starts from zero working features and has to catch up with a moving target. Joel Spolsky called rewriting code from scratch the “single worst strategic mistake” a software company can make, using Netscape’s lost years as the example (Joel on Software, 6 April 2000). AI tools make a rewrite faster to start. They do not make it faster to reach everything the old version quietly did.
Why “just patch it” can be riskier still
AI-generated code tends to look finished before it is. A 2025 study by Veracode tested code from over 100 large language models and found 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities (Veracode, 2025 GenAI Code Security Report). Patching the visible bugs without looking at data access, secrets and sign-in leaves the expensive problems in place.
What to ask for before you decide
- A written recommendation per part — keep, fix or replace, with the reason.
- What the recommendation assumes — users, data, integrations, regulation.
- What is not included in either option.
- How the switch happens — all at once, or part by part with the old version still running.
How Pricient handles the decision
Your prototype is the requirements document. Describe what you built and what is going wrong; today a person runs the intake with you by email. Before you pay anything you receive the specification, wireframes of every screen, the Not in this release list, the assumptions register and a three-tier itemized quote — with what is kept and what is replaced written into it, not left to a call.
The launch-ready MVP starts from $7,500, fixed once your spec is agreed: live 3 weeks after the spec is agreed, security-hardened, 80% test coverage and three months of support. Code you share is read-only, logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.