Choose redesign when evidence points to problems that can be resolved within the existing product and architecture. Consider rebuilding when consequential requirements cannot be met credibly through focused changes, and the business can fund migration and continued operation. Compare incremental repair and replacement against the same user outcomes rather than treating either as the default answer to an ageing interface.
Let’s plan your app redesign.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Separate symptoms and causes
Collect observed task failures, support records, performance evidence and engineering constraints. A slow screen may result from a query, a network dependency or the interface itself. A redesign will not necessarily resolve a backend bottleneck, and a rewrite will not automatically clarify a confusing business process.
State which diagnosis is supported and which remains a hypothesis. Ask the current team to demonstrate constraints rather than accepting “legacy” as a complete technical explanation.
Compare the interventions
| Evidence | Intervention to investigate | Further work to price |
|---|---|---|
| Users cannot understand a task | Focused UX redesign | Task research and validation |
| One dependency causes delays | Targeted technical repair | Integration and regression checks |
| Repeated structural constraints block required change | Architectural improvement or replacement | Feasibility and transition plan |
| Unsupported operating dependencies | Maintenance or replacement assessment | Compatibility and release work |
| Data is inconsistent | Ownership and migration work | Reconciliation and correction |
| Several causes interact | Sequenced combined programme | Operating continuity and decision gates |
The table suggests investigations, not automatic conclusions. Evaluate the product-specific evidence and consequences.
Use a bounded change experiment
Suppose a hypothetical ordering app has abandonment around address entry. Observe the task and inspect errors before proposing a complete rebuild. A focused interaction and validation change may test the relevant hypothesis.
If evidence instead shows that required permissions cannot be enforced under the proposed architecture without substantial restructuring, investigate the technical alternatives and their transition costs. Keep those findings separate from opinions about the appearance of the interface.
Price the transition, not just the new build
Include data migration, user retraining, integration changes, account continuity and the period of operating old and new systems. Define which source remains authoritative during transition.
Test open transactions, saved links, outstanding notifications and partially completed work. A new application can reproduce the visible screens while failing to preserve important business history or ongoing commitments.
Preserve useful evidence and ownership
Keep supported behaviours, transaction definitions and actual failure cases available to the implementation team. Avoid relying on the old codebase as the only specification.
Agree the release boundary, recovery plan and success measures before committing to a replacement date. Assess improvement through the original tasks and constraints, not the novelty of the technology stack.
Questions product owners ask
Is rebuilding always cheaper than improving old code?
No. Compare scoped options, uncertainties and transition work. The age of the code alone does not settle the decision.
Can redesign and rebuilding happen together?
Yes, but separate the hypotheses and acceptance evidence so the project can explain what each change is meant to solve.
Prepare the decision review
Bring observed failures, technical evidence and open-work examples. Use the UX audit deliverables guide and mobile app development overview to compare practical interventions.
