A useful repair-versus-rebuild decision starts with the working customer journey and evidence about the remaining problems. The fact that AI assisted the code does not settle that decision.
Separate the validated idea from the current implementation
Write down what users should accomplish and which parts you have tested with them. Keep the useful interface decisions, content and workflows in view. Replacing code should not automatically discard everything learned about the product.
Then establish a reproducible starting point: source access, a working development environment, account ownership, the current deployment and a short list of issues. If nobody can reproduce the app, the first paid task may need to be a bounded investigation rather than a confident fixed repair quote.
Compare the two options against the same job
| Question | Evidence that supports repair | Evidence that may support replacement |
|---|---|---|
| Does the main journey work? | A repeatable flow with isolated failures | Core behavior cannot be reproduced or differs materially from the intended job |
| Can the team work on the project? | Editable source, accounts and a documented build | Missing source or a platform limitation that prevents the required change |
| Are data and permissions understandable? | Named ownership rules and bounded corrections | Major data-model or access assumptions conflict with the product's requirements |
| What changes during migration? | Existing data and working integrations stay in place | A replacement has a realistic migration, cutover and rollback plan |
| Can the quoted work be bounded? | Named fixes and acceptance tests | A replacement solves the agreed job more predictably at an explained total cost |
These are decision prompts, not an automated score. One serious permission issue may matter more than twenty visual defects. An unfamiliar codebase may need investigation before either option can be quoted responsibly.
Ask what a repair quote actually covers
A repair scope should name the affected workflow, the issue to correct, tests that demonstrate the correction, the approval environment and the handover. “Finish the app” is too broad if it also means redesigning screens, introducing subscriptions and changing a database.
Separate required launch blockers from improvements you can defer. Decide who approves staging and the production release. Include provider charges, data migration and support responsibilities explicitly.
A replacement needs a migration plan
A new implementation still has to serve existing users. Inventory the accounts, customer data, media, integrations, important URLs and email configuration that need to survive. Explain who controls the domain and provider accounts and how to return to the old system if the cutover fails.
For website moves that change URLs, Google's migration guidance recommends mapping URLs, handling redirects, testing and monitoring. Search visibility can fluctuate; replacement should not be sold with a blanket promise of unchanged rankings.
Compare the total, not the cheapest first step
Include diagnosis, engineering, tests, approvals, migration and the support work you expect to need. A cheap repair that repeatedly fails can cost more than a bounded replacement. An unnecessary rebuild can also add cost and discard a useful working product.
No project prices in this guide represent an actual rescued client's costs or savings. BYBOWU's published new-build starting prices are on the pricing page; a repair price follows inspection of the existing project.
Start with an inspectable recommendation
Our $1,490 App Launch Review covers an eligible web app with one database, up to two named roles and three critical workflows. It produces documented findings and repair options. The review itself does not include a rebuild, production launch or unlimited source inspection.
For a simple marketing website without accounts or custom payments, the Review & Publish package may fit instead. An idea with no existing product belongs in our current planning-sprint path.
Get a review before deciding to rebuild. Include the existing preview and the problem you need resolved. The first reply confirms fit and the proposed scope; it is not a promise that a complete review will arrive within one business day.