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 guideMaking product discovery feel instant without replacing the existing platform.
A business with a large product catalogue needed customers to find the right products faster.
The existing platform still carried product data, publishing workflows and operational knowledge that did not need to be replaced.
A dedicated search layer improved the customer experience while the platform stayed in place.
The situation
The existing ecommerce platform already worked. It managed products, supported publishing and held the operational knowledge the business depended on.
Over time, the catalogue had grown significantly. Customers could access a large range of products, but finding the right one quickly had become harder.
Search relied too heavily on exact keywords. If customers did not know the right phrase, spelling or category, relevant products were easy to miss.
Replacing the platform would have created unnecessary cost and risk. The constraint was not the whole system. It was product discovery.
- Existing platform already worked
- Large product catalogue
- Exact keyword search
- Slow product discovery
- Unnecessary replacement risk
The instinct
REPLACE THE PLATFORM.
It sounded attractive. If customers cannot find products, a new platform can look like the cleanest way to reset search, catalogue structure and customer experience at once.
But that framed the problem too broadly. The platform was not failing. The discovery layer was.
Replacement would have delayed the improvement customers needed, moved stable workflows into migration risk and made the business pay again for systems that still worked. The better decision was to add one focused capability beside the platform.
The technical judgement
The work separated the product discovery problem from the platform replacement question.
Introduce a dedicated search layer.
Search needed specialist capability without forcing the whole platform to change around it.
Keep the existing CMS.
The CMS already supported publishing and product management. Replacing it would have added risk without solving the main constraint faster.
Preserve operational workflows.
The team could keep managing products, content and business rules in familiar systems.
Improve discovery independently.
Search relevance, speed and filtering could improve without waiting for a larger platform project.
Separate search capability from platform.
A dedicated layer made search easier to tune, test and improve over time.
Make future improvements easier.
A clearer search architecture created a stronger base for later discovery and AI assisted experiences.
What changed
Product discovery felt faster
Customers could move from intent to useful product options with less effort.
Exact wording mattered less
Useful results became easier to find even when customers did not know the right product name.
Relevant products surfaced sooner
The experience could respond to what customers were trying to find, not only how the catalogue described it.
Product content worked harder
Existing product information became more useful for search, filtering and future discovery improvements.
Support friction reduced
The website answered more product finding questions before customers needed help from the team.
Search could keep improving
Discovery improvements no longer depended on a broader platform replacement.
What stayed the same
Preserving stable systems was part of the strategy.
The existing CMS stayed in place because it still supported the business. Product management, publishing, integrations and familiar internal processes did not need to be rebuilt to improve discovery.
The business kept the systems that already carried operational knowledge. The search layer sat alongside them instead of forcing a migration.
Changing less made the improvement faster, lower risk and easier for the team to adopt.
- CMS
- Product management
- Publishing workflow
- Existing integrations
- Business processes
Outcome
Faster product discovery.
Reduced support friction.
Existing platform preserved.
Lower replacement risk.
Stronger foundation for future AI assisted discovery.
One focused capability created the biggest improvement.
Key lessons
Improve before replacing.
A working platform often contains value that should be preserved while the specific constraint is improved.
Separate capability from platform.
Search can improve as a focused layer without turning the whole project into a replacement.
Better search creates business value.
Product discovery affects how quickly customers understand the catalogue and find a path forward.
Incremental architecture compounds.
One clear capability can create a stronger foundation for later improvements.
Preserve what already works.
Keeping stable systems in place can be the decision that makes improvement possible.
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