Should You Fix Unfinished Software or Rebuild It?
A business-first way to decide whether a half-built app, portal, or internal tool deserves repair, replacement, or retirement.
Who this is for
Established owners who inherited or paid for software that partly works but cannot be trusted, launched, or maintained confidently.
You already have sunk cost, operating knowledge, and perhaps live data. A fashionable rewrite can destroy useful assets, while endless patching can preserve the wrong system.
The short answer
Do not decide from code aesthetics or frustration. Compare the cheapest safe path to the required business outcome, including data migration, operational disruption, hidden dependencies, and the value of what already works.
What to do in the first hour
- 1.Define the required outcome in operational language: who needs to do what, with which data, under what time and reliability constraints.
- 2.List the current system's proven assets: usable workflows, clean data, integrations, customer adoption, domain knowledge, tests, and deployment knowledge.
- 3.List the liabilities separately: security exposure, inaccessible code, obsolete dependencies, corrupt data, unreliable releases, confusing workflows, and expensive manual workarounds.
- 4.Freeze nonessential feature requests until the keep-versus-replace decision is supported.
Diagnose before you buy another solution
Repair is favored when the core architecture can support the needed workflow, data is sound, deployment is reproducible, and most risk is concentrated in a few known components.
Replacement is favored when the current system cannot be safely changed, the business model has fundamentally changed, critical dependencies are unsupported, data boundaries are broken, or every release causes unrelated failures.
A hybrid is common: stabilize production, extract and clean the data, replace one risky boundary, and retire the old system in slices. This often captures the value of a rebuild without betting the business on a single cutover.
A practical recovery plan
Run a technical sanity check
Inspect the repository, dependency health, data model, permissions, deployment, error logs, tests, and one representative workflow. Record verified facts, unknowns, and experiments needed. A screenshot review cannot answer fix-versus-rebuild.
Price the whole path
For each option estimate discovery, engineering, migration, parallel operation, staff retraining, downtime risk, vendor costs, compliance work, and maintenance. Include the cost of delayed business value and the cost of a failed cutover.
Test the riskiest assumption
Spend a small fixed amount on the uncertainty most likely to change the decision: can the old data be migrated, can the deployment be reproduced, can the failing integration be isolated, or can the critical workflow meet its load target?
Choose a reversible first milestone
A repair milestone should make one workflow safe and observable. A rebuild milestone should prove the new architecture with real data before broad feature work. Both need acceptance evidence and a rollback path.
Set a stop rule
Agree in advance which discovery would end the repair path and which failure would pause the rebuild. Stop rules prevent sunk-cost emotion from silently turning a bounded experiment into another endless project.
Questions to ask before approving more work
- Which parts have been verified in code, logs, data, and a real deployment?
- What useful asset would be lost by rebuilding?
- What risk cannot be removed by repairing only the critical path?
- How will data be reconciled during migration and how do we prove no records were lost?
- What is the earliest milestone at which the business receives usable value?
Red flags
- — A developer recommends rewriting in their preferred technology before inspecting data and operations.
- — The repair plan is an unranked list of every bug anyone has reported.
- — Migration is described as simply exporting a spreadsheet without reconciliation.
- — The estimate excludes training, parallel operation, integrations, and cutover support.
- — Nobody can explain how the old system will be recovered if launch fails.
When to bring in specialist help
Security, regulatory, payment, medical, financial, or irreplaceable customer-data systems need specialist review before continued operation or migration. If a live defect is actively corrupting data, stabilize and preserve evidence before debating architecture.