Deciding Whether to Stop an In-Flight Platform Rebuild
An anonymous platform engagement stopping a full rebuild and redirecting engineering toward the existing product, with a forward-looking decision record.
The replacement project was already under way
A company had committed to a full platform rebuild using a new technology stack and architecture. The existing product remained usable, but customers raised user-experience concerns and engineers found the code difficult to maintain. The replacement had become the proposed answer to both problems.
Ampity's work on this anonymous engagement concerned a decision to stop that rebuild and redirect engineering to the existing platform. The described transition retained lessons from the replacement effort for incremental improvements. It was a decision about work still ahead, not a rule that rebuilding is always wrong.
Reopen the objective before defending the project
A replacement can be late while still addressing a requirement the existing platform cannot meet. It can also consume more work without resolving the customer problem that justified it. A useful review separates the intended product outcome from the chosen implementation.
For a comparable decision, identify which customer or operating requirement remains unmet, what each option would change, and what the team must keep supporting during the transition. Code quality and user experience are different concerns. A new stack does not, by itself, resolve either one.
The account records continuing the rebuild and stopping it in favour of the existing product as the alternatives considered. Narrowing a replacement to one capability or pausing it for a bounded investigation are additional options another team could examine. They are not decisions attributed to this engagement.
Compare remaining obligations rather than a progress percentage
Money already spent cannot demonstrate that another increment of spending is worthwhile. HM Treasury's Green Book discussion of sunk costs separates irrecoverable past expenditure from decisions still available, while retaining the alternative uses of resources. Its formal appraisal framework concerns UK public spending; only that general distinction is used here.
Stopping also has future obligations. The existing platform still needs an owner, and a replacement may have support contracts, retained data or work that cannot simply be abandoned. Compare the remaining delivery, transition and operating responsibilities of each option. Do not treat stopping as a zero-cost alternative or turn the full unspent estimate of a rejected option into cash saved.
An estimated percentage complete does not identify the work on the critical path, acceptance still outstanding, migration effort or the uncertainty of integration. Dividing elapsed time by that percentage would assume a stable, comparable unit of completed work and a constant rate. Those assumptions are not established by this case.
The finance owner would need dated cash obligations, available funding and explicit scenarios before making a liquidity assessment. A delivery estimate and a financing scenario should not be collapsed into a prediction that the company will survive or fail.
Put one disputed capability into the decision packet
Begin with authorized read-only inspection of the agreed objectives, accepted delivery records, remaining dependencies and owner-supplied estimates. Keep contracts, customer records and financial details in their permitted environment.
The following filled comparison is synthetic guidance, not the engagement's requirements or a review that was executed. Assume a replacement contains a reporting capability whose export contract has not been accepted. The existing product can still provide the currently agreed report, but a requested change remains unresolved.
| Option to examine | Stipulated remaining responsibility | What would inform the decision | Current disposition in this example |
|---|---|---|---|
| Continue the replacement | Complete the export contract, compatibility review and transition work | Accepted scope and dependent work, not a count of implemented screens | UNKNOWN until the remaining obligation is defined |
| Narrow the replacement | Retain only the proposed reporting capability | Whether it can operate without unaccepted replacement dependencies | A separate option to estimate, not automatically reusable work |
| Redirect to the existing product | Maintain the current report and assess the requested change | A bounded change proposal and an owner for ongoing support | Candidate for comparison, not a proven faster route |
| Stop replacement dispatch | Preserve necessary records and identify commitments that remain | Responsible owners and an authorized disposition for each obligation | Stopping work is not evidence that every cost or effect has ended |
A capability is not accepted merely because its screens are implemented, and reused code is not free if its dependencies still require support.
Redirect work without abandoning state or ownership
The recorded transition returned engineering attention to the existing platform and applied lessons from the rebuild to incremental work. The exact disposition of replacement environments, data and contractual commitments is not established.
For another team, name who owns the retained product, unfinished artifacts, outstanding customer commitments and any already accepted writes or external effects. A project-stop decision is not permission to delete an environment, cancel a contract or route customers to an earlier implementation.
Where a proposed transition involves incompatible application state, Amazon's rollback-safety discussion explains why restoring an older artifact does not establish a compatible reader. That is a general review question, not proof that this engagement migrated data or performed a rollback.
Any later compatibility exercise needs separate authorization for an isolated environment, synthetic or approved sanitized data, scoped identities and non-delivering integrations. Stop if it reaches a live customer destination or loses the records required for reconciliation. The recovery owner must account for effects already accepted; stopping new work does not undo them.
What this decision does not prove
The account supports the stop-and-redirect choice and the described reuse of lessons. It does not establish investment amounts, completion forecasts, extended runway, feature throughput, revenue recovery, fundraising or company survival. No personnel outcome or blame judgment is published.
Ask for the next decision, not a defence of past spending
Choose one disputed capability and write its remaining acceptance, transition and support obligations for each feasible option. Have the product, engineering and finance owners resolve the first UNKNOWN before presenting a recommendation as affordable or deliverable.
Keep the decision dated and state what new evidence would reopen it. Continuing, narrowing and stopping all need ownership; the amount already invested does not supply that ownership or select the answer.
Technical reference
HM Treasury's Green Book and Amazon's rollback-safety discussion were read on 18 October 2026 for the limited future-cost and compatibility distinctions linked above. Neither establishes this engagement's finances, delivery record, transition implementation or outcomes.