Decision making
Should you rebuild or modernise your website?
A practical way to decide whether a rebuild is worth it, or whether focused modernisation creates more value with less disruption.
Read the guideModernising a large membership platform without slowing delivery.
A growing membership platform needed to keep delivering new features while improving maintainability.
A full rebuild sounded attractive, but it would have slowed delivery and increased risk.
Instead, the platform was modernised incrementally while remaining in active use.
The situation
The platform already served a large member base. People depended on it, internal teams understood its workflows and the product roadmap could not simply pause while the technical foundation was improved.
New features had already been committed. At the same time, technical debt was making delivery slower, performance was beginning to suffer and small changes were becoming harder to make with confidence.
The problem was not that everything was broken. The problem was that the system was becoming harder to improve while the business still needed it to keep moving.
- Large existing member base
- Active product roadmap
- New features already committed
- Technical debt increasing
- Performance beginning to suffer
The obvious solution
LET'S REBUILD.
It sounded reasonable. A fresh build promised cleaner code, fewer old decisions and a chance to fix everything at once.
It would have been the wrong decision. The platform still carried active members, committed features and business rules the organisation already relied on.
Starting again would have moved the risk rather than removed it. The better decision was to improve the parts slowing delivery while protecting the value already inside the system.
The technical judgement
The work started by separating what should change from what should stay. That distinction made the modernisation practical.
Improve architecture
The platform needed a clearer technical foundation so future work could be planned and changed with less uncertainty.
Keep existing business logic
The business rules already carried operational knowledge. Preserving them reduced risk and avoided relearning decisions the organisation had already paid for.
Reduce duplication
Repeated patterns were making changes slower and less consistent. Removing duplication made the platform easier to reason about.
Increase consistency
Consistent structures helped developers make similar decisions in similar places, which improved confidence across the codebase.
Create reusable frontend patterns
Shared interface patterns gave the team a stronger base for new features without forcing every feature to start from scratch.
Improve delivery confidence
The goal was not only cleaner code. It was a delivery environment where changes felt safer and easier to sequence.
What changed
Reusable UI patterns
Repeated interface work was consolidated into patterns the team could use across future features.
Improved architecture
The structure became clearer, which made future decisions easier to understand and discuss.
Performance improvements
Slower parts of the experience were addressed without turning performance work into a separate rebuild.
Cleaner component structure
Components became easier to maintain, reuse and reason about during active delivery.
Reduced duplication
Common logic and repeated implementation details were simplified so changes had fewer places to drift.
More predictable releases
Incremental change reduced the risk that modernisation would interrupt committed product work.
What stayed the same
Changing less was part of the strategy.
The existing business workflows still mattered. The platform already reflected how the organisation served members, handled internal processes and delivered value.
Existing users, operational knowledge, release cadence and the product roadmap were not treated as obstacles. They were constraints worth respecting.
Preserving those parts meant the modernisation could happen around the work that already mattered instead of forcing the business to wait for a cleaner technical story.
- Business workflows
- Existing users
- Operational knowledge
- Release cadence
- Product roadmap
Outcome
Delivery kept moving.
The platform became easier to change.
Repeated patterns became clearer.
Future work had a stronger foundation.
The business did not need to pause useful product work to make the system healthier.
Nothing dramatic happened. That was the point.
Decisions we deliberately didn't make
We did not rebuild the platform.
Replacement would have slowed committed work and forced the team to recreate business knowledge that was already working inside the system.
We did not replace business workflows.
Existing workflows carried operational knowledge. Preserving them kept the modernisation connected to how the organisation served members.
We did not interrupt the release cadence.
The roadmap still mattered. Incremental change allowed technical improvement to happen while delivery continued.
We did not redesign the member experience for novelty.
Members needed a stable service, not visible disruption. Improvements focused on making the platform easier to maintain and extend.
We did not make architecture a separate project.
Architecture changed where it reduced future decisions and supported real delivery work.
Key lessons
Improve before replacing.
A working system often contains value that should be protected, not discarded.
Architecture should reduce future decisions.
Good structure makes the next round of work easier to plan, explain and deliver.
Preserve business value.
Existing workflows and operational knowledge are part of the system, even when the code needs improvement.
Modernisation is a strategy, not a rewrite.
The useful work is often a sequence of careful decisions rather than one large replacement project.
Consistency compounds.
Shared patterns make every future change a little easier to make with confidence.
Related insights
Practical writing related to the same services and technical decisions.
Technical strategy
Technical debt isn't always the biggest problem.
The visible problem is often the codebase, but the deeper constraint is usually decision quality, ownership or technical direction.
Read the strategy noteAI and automation
Where AI actually creates business value
A practical way to spot AI opportunities that reduce effort, improve consistency and make existing systems easier to use.
Read the AI insight