Ecommerce website rebuild or targeted improvements: what do you need?
An ecommerce website rebuild makes sense when the current store cannot support essential buying or operating tasks. If the problem is unclear product information or a broken template, a focused improvement may be enough. Start with the task customers cannot complete, then choose the scope.

In this article
Overview
An ecommerce website rebuild makes sense when the current store cannot support essential buying or operating tasks. If the problem is unclear product information or a broken template, a focused improvement may be enough. Start with the task customers cannot complete, then choose the scope.
Name the customer task before the design problem
Replace ‘the website feels old’ with an observable problem: shoppers cannot tell two products apart, a variant is hard to select on mobile, or the team cannot maintain the catalog. Those problems lead to different scopes. Ask a person unfamiliar with the brand to complete the task and record what happens.
Use traffic and order data to set context, but do not assume that a conversion-rate change proves a design cause. Visitors, offers, stock and campaigns may have changed too. The walkthrough gives the team a specific thing to investigate.
From symptom to scope
Observe
A real shopper task fails or becomes confusing.
Locate
Is the problem in content, a template or the underlying store?
Test a repair
Find out whether a contained change resolves the task.
Scope the work
Choose the smallest credible implementation.
Gymshark: a rebuild case with a concrete failure
In Shopify’s Gymshark case, founder Ben Francis describes an eight-hour Black Friday outage and estimates £100,000 in lost sales. The account concerns the brand’s 2015-era infrastructure and later move to Shopify Plus. It is a useful rebuild example because the problem is identifiable; it is also a vendor-published historical account, not a universal platform comparison.
Be equally specific about your store. Perhaps an integration fails during launches, inventory falls out of sync across markets, or a simple product update requires fragile custom code. Ask a developer to show whether the problem comes from the platform or from something that can be repaired.
Give the repair option a fair examination. A known failure can sometimes be resolved by removing one dependency or improving one template. Conversely, a collection of small repairs can become more expensive than replacement when each depends on the same unsupported architecture. The proposal should explain that tradeoff in terms of risk, maintenance and customer tasks, with an acceptance test for every capability the new build promises.
Two stores with low conversion can need different fixes
Imagine two small stores with disappointing conversion. Store A has a stable purchase flow but its product images do not communicate size, and delivery information appears too late. Store B repeatedly loses order synchronization during launches. These are original planning examples. They should not receive the same solution simply because both owners ask for a redesign.
For Store A, a focused content and template project could supply an in-scale product photograph, clearer variant information and visible delivery terms. Christian Holst’s research gives a specific usability question to test: can a new shopper judge the item accurately? For Store B, investigate the synchronization fault, the available integration options and the cost of maintaining the current architecture before recommending a rebuild.
Ask what your team will be able to do after each project. A focused repair should leave content that is easy to maintain and a working purchase path. A rebuild also needs product migration, integration checks, preserved search destinations, training and a recovery plan. Include those tasks in the proposal before approving the design.
| Situation | First scope to investigate | Evidence of completion |
|---|---|---|
| Product size and contents remain unclear | Product content, photography and template repair | New shoppers can explain the exact item and select it. |
| Recurring operational failure | Integration diagnosis and a repair/rebuild comparison | Orders and stock remain consistent through the required workflow. |
| Routine edits require specialist intervention | Editing model and team handoff | The intended owner completes the recurring tasks. |
From a failed task to accepted work
Observe
Name a failed customer or operating task.
Compare
Price repair and rebuild against the same requirement.
Accept
Test the capability before signing off the work.
Compare three ordinary situations
Use these three situations to compare the work a store might need. They are planning examples. If several problems occur together, ask the agency which must be fixed first and which can share the same project.
| Situation | First scope to investigate | What would justify more work |
|---|---|---|
| The product is hard to understand, but buying works. | Rewrite and reorganize key product information; add a useful demonstration. | The template cannot display the needed product distinctions accessibly. |
| Mobile variant selection fails across many products. | Repair the shared component and test representative products. | The current architecture cannot support the required catalog behavior reliably. |
| The business needs new purchasing capabilities. | Document the must-have tasks and investigate existing options. | The required experience is incompatible with the current store after a technical review. |
What is the store struggling to do?
Choose the closest symptom. This is a starting point for investigation, not a diagnosis.
Investigate a focused content and page repair
If the store supports buying and maintenance, improve the product explanation, comparison and purchase information first. Test the same customer task after the change.
Check next: Can the current template display the information shoppers need?
A focused repair can be a complete project
Imagine a European skincare brand with four products and a working Shopify checkout. US visitors reach the store, but the difference between two moisturizers is unclear. The first scope could be a side-by-side comparison, clearer variant labels, a short texture demonstration and visible delivery information.
Test the result with someone new to the brand: can they tell the moisturizers apart, choose one using the available facts and complete checkout on a phone? Repeat that task after the changes. Then review store results over time, taking account of changes in traffic, price and stock.
What would justify a full rebuild?
A rebuild can make sense when a store repeatedly blocks required work and contained repairs cannot solve it. Document the customer and team tasks the new site must support, the assets that can be reused, and the maintenance responsibilities after launch.
Ask for an alternative repair scope alongside the rebuild recommendation. Compare what each option solves and leaves unresolved. Price and timeline should follow that investigation; a generic promise of a fast rebuild hides the dependencies that most affect the result.
- Required buying tasks are written down.
- The current store's limitations have been demonstrated.
- A smaller repair option has been considered.
- Content, integrations, approvals and support have named owners.
- Search continuity and launch checks are in scope.
Keep the useful parts of the existing store
Capture the current page inventory, useful content and baseline search performance. Preserve working URLs where possible and plan any necessary changes explicitly. The launch review should include navigation, important destinations, indexing controls, checkout and measurement.
Include this work in the quote before choosing a rebuild. The detailed migration plan will depend on your store, but it should protect pages and information customers already use. A visual redesign still needs to preserve those routes into the business.
What carries into the new scope
Working URLs
Preserve useful destinations and existing links.
Product knowledge
Keep accurate facts and the explanations customers use.
Store operations
Confirm catalog, payments, delivery and ownership.
Measurement
Retain a baseline and check the new purchase path.
Ask for a proposal you can compare
Request the problem, recommended scope, deliverables, dependencies and acceptance checks in plain language. For the moisturizer example, the proposal should say which pages and templates change and what assets the brand must approve.
Dahna can scope focused website improvements or a broader build and connect the result to marketing. The best fit depends on the actual work needed, not on selling every brand the largest project.
Ask the agency to demonstrate the finished task, not just deliver new screens. For the moisturizer example, acceptance means a new shopper can compare the two products, select an available variant, see the delivery information and complete a mobile purchase. The table below turns those expectations into reviewable work.
| Work in scope | What the team delivers | How you accept it |
|---|---|---|
| Product comparison | Approved differences shown on the relevant pages | A new reader can explain the difference without help from the founder. |
| Shared product template | Working variant controls on representative products | Test available and unavailable variants on a phone. |
| Purchase path | Delivery information, working checkout and checked purchase tracking | Compare a controlled test order with its store and analytics records. |
| Search continuity | An inventory of important URLs and any proposed changes | Existing destinations still work; any migration is reviewed before launch. |
| Handoff | Editable content, account access and named support owner | The brand can make the routine update it expects to manage. |
Compare the two proposals
Prepare a repair-versus-rebuild comparison with evidence, dependencies, launch risks, ongoing ownership and a concrete definition of done for both options.
Use the downloadable planning sheet linked below to adapt the examples to your brand. Add the current product information, the person responsible for each task and the check that will show the work is complete. Keep unanswered questions visible for the project discussion.
About the sources
Shopify published the Gymshark history and Ben Francis’s estimate of £100,000 in lost sales during the eight-hour outage. Treat that as a founder estimate in a vendor case study. It does not establish that a platform change caused Gymshark’s later growth.
Christian Holst’s May 2017 Baymard article reports observed confusion about product size. It supports testing whether shoppers can judge scale on your page; it does not predict a conversion-rate increase from a particular image.
Sources & further reading
Discuss the right website scope
Dahna can review the buying or maintenance problem and compare a focused fix with a larger build. The proposal should explain what each option solves, what it costs to maintain and how your team will know the work is complete.
Why consider Dahna for this work?
Dahna brings bilingual Korean and English strategy together with creator, content, and measurement work for brands growing in the US. You can review the people behind the recommendations and the kind of work we propose before starting a conversation.
Founder experience includes prior and contracted roles. Sample deliverables illustrate our approach; they are not client results or a performance promise.
We’ll agree on deliverables, responsibilities and approvals before work begins.



