The useful starting point
Ask for evidence about the code and the product before choosing a rebuild. A useful review should explain the options, their risks and the next deliverable.
Start with the product, then inspect the code
Write down what the next release must let a user do. Separate that from the longer wish list. An application can have untidy code and still contain useful working journeys. It can also look polished while important transactions or operational tools remain incomplete.
The review should connect the implementation to those journeys. Can someone complete the important task? What happens if an outside service fails? Which parts require manual intervention? Those questions make the review useful to the person funding the work.
A decision matrix for a first code review
Compare the same next release across three routes. The table below is a way to organise evidence; it does not decide the result before someone has inspected your application.
| Route | Evidence to look for | A useful first delivery | Risk to investigate |
|---|---|---|---|
| Improve the existing system | Core journeys work; the team can build, test and deploy it | Repair one blocked journey and demonstrate the release | Hidden dependencies outside the area being changed |
| Replace a bounded component | A difficult area has a clear boundary and a stable interface | Run a replacement behind that boundary with a rollback plan | Inconsistent records while old and new components coexist |
| Rebuild the product | Required journeys differ substantially, or the current foundation prevents necessary work | A complete user journey plus a tested migration slice | Recreating less-visible operational features and moving existing data |
Ask the reviewer to point to something observed for each recommendation: a deployment attempt, a test result, a dependency or a user journey. An opinion about the code’s appearance is a weak basis for committing the next budget.
A worked example: keep the working journey, isolate the obstacle
Illustrative example · a planning scenario, not a client incident
Suppose customers can sign in, place requests and view their history, but an external integration blocks the next launch. The first question is whether that integration can be repaired or replaced while preserving the working journeys.
- 1Reproduce the blocked journey
- 2Inspect its dependencies and data
- 3Compare repair, replacement and rebuild
- 4Agree a demonstrable first delivery
If a limited change succeeds, it produces evidence for keeping the foundation. If it exposes a deeper constraint, that finding improves the rebuild estimate. The point is to make the next commitment informative, rather than paying to rediscover the same uncertainty in a larger project.
What a useful handover from the review contains
- Observed facts: what the reviewer ran or inspected, with references the team can find again.
- Options: the same product scope compared across plausible routes.
- Unresolved dependencies: account access, outside services, data or product decisions still needed.
- First delivery: a specific outcome someone can demonstrate and a way to decide what follows.
These items also help a second team understand the recommendation. The review should remain useful after the presentation ends.
Compare three options
Keep the foundation and improve it
This can make sense when the important flows work, the system can be deployed and tested, and the next changes fit its structure. The work may be concentrated in a few areas rather than spread across everything.
Replace selected parts
A difficult integration, fragile app screen or isolated service may be replaceable without moving the whole product. The boundary matters: a partial replacement needs a clear way to exchange data and a plan for the period when old and new code coexist.
Rebuild the product
A rebuild may be justified when the required product has fundamentally changed or the existing foundation cannot support the necessary work. It still needs an explanation of what will be migrated, how operations will continue and when the replacement can take over.
Ask what the estimate includes
Compare options against the same scope. A rebuild estimate that excludes data migration, administration, app-store releases or existing integrations is not comparable with an estimate to improve the running product.
- Which user journeys are included in the first delivery?
- What happens to existing users and their data?
- Who owns the hosting, stores and outside-service accounts?
- How will the team show that a change is safe to release?
- Can the work be delivered in useful stages?
Make the next commitment small enough to evaluate
A review should leave you with a written recommendation, the reasons behind it and the remaining unknowns. Ask the team to distinguish something they observed from something they still need to investigate.
Then agree a first delivery that tests the recommendation. That might be one repaired journey, a repeatable deployment or a well-defined replacement boundary. The right milestone depends on what the review finds; it should give you a firmer basis for the next decision.
What our payments takeover demonstrates
In our payments engagement, we began with an existing codebase that was not ready to launch. We stabilised it and scoped the work needed for payments and compliance; the first app went live two months after handover. A second consumer app and a business portal followed within the continuing product relationship.
The useful evidence is the sequence: existing code, a defined launch, then further products on the platform. It supports discussing a staged takeover as an option. It does not decide whether another codebase should be kept; that depends on the findings of its review.
Common questions
Is old code a reason to rebuild?
Age alone does not answer whether a system can support the next product goal. Start with the journeys, dependencies, ability to release changes and requirements that actually matter.
Can a takeover happen in stages?
Often the useful planning question is which responsibility or component can move first. Whether that is feasible depends on interfaces, access, data and the running operation; a review should explain those dependencies.