A visual refresh, a theme rebuild and a catalogue restructure solve different problems, cost different amounts, and are frequently confused for one another.
Redesign briefs arrive already written. The blockage is often somewhere else.
Most redesign enquiries open the same way: the store looks dated, the team wants something modern, and a launch date has already been mentioned. All three statements can be true while the money still ends up in the wrong place.
A store that looks dated and converts badly is not necessarily a store with a visual problem. If shoppers cannot reach the right product, the constraint is navigation, collection structure and merchandising, and a new theme relocates that problem to a better-looking page.
A store the team cannot change is not a visual problem either. That is a theme problem: sections that were built for one campaign, settings nobody documented, and copy hard-coded into templates. The fix is structural, and the visible result can be modest.
Sometimes the store genuinely does look dated, everything else works, and a refresh is the right and cheapest answer. The point of diagnosis is to be able to tell.
The same brief, priced three ways, depending on the answer.
| Project | What changes | What it will not fix |
|---|---|---|
| Visual refresh | Typography, colour, spacing, imagery treatment and component styling inside the existing theme | Navigation depth, collection logic, template limits or a theme the team cannot edit |
| Theme rebuild | The template and section architecture, the settings the team uses, performance and the editing model | A catalogue that is organised badly, or products that are described badly |
| Catalogue restructure | Collection architecture, sub-collections, filtering, tagging, metafields and merchandising rules | A theme that is genuinely obstructive, or a visual identity that undersells the brand |
These combine, and often should. The reason for naming them separately is that a combined project should be a decision, not an accident of scope.
Observable in the store and in the admin, before any research is commissioned.
These are the patterns that tend to mean the visible design is not the expensive part.
New ranges were added as tags, then as collections, then as menu entries, and nobody removed anything. Shoppers now meet several near-identical routes to the same products, and search engines meet several near-identical pages.
Copy is inside templates, campaign sections were built for a specific promotion, and the theme editor exposes settings nobody trusts. The backlog is full of ten-minute changes that take a fortnight because of the process around them.
The flagship range looks right and everything else is padded out or truncated. That is a template architecture problem, and restyling it makes both cases slightly better looking and no easier to sell.
Filtering, navigation and comparison all behave differently on a phone, usually because they were designed on a desktop and adapted afterwards. Most stores take most of their traffic the other way round.
Name the constraint first. The design brief follows it.
The store keeps taking orders throughout. That constrains the method.
A live store cannot be rebuilt in place, and a long unpublished branch collects conflicts. The work is staged so that trading is never paused for the convenience of the build.
Keeping the previous theme is the rollback. It is unglamorous and it has saved more launches than any amount of pre-release testing.
Published starting figures in GBP and USD, excluding VAT.
From-price or scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
A visual refresh inside an existing theme is usually a bounded project. A theme rebuild with a catalogue restructure is a larger piece of work, and the difference between them is a diagnosis rather than a preference.
Often, and it is worth checking before committing to a rebuild. A well-built theme with a clean section architecture usually has more room in it than the team expects. Where it is genuinely obstructive we explain which parts and why, in terms of the changes it makes difficult.
It can, if URLs, internal linking, metadata or content are changed without a plan. We inventory the routes that earn traffic, hold them constant where possible, and redirect them one hop where they genuinely have to move. What we do not do is promise rankings will improve.
No, and on a trading store there is usually a good argument for not doing so. Templates can be rebuilt in sequence behind the scenes and published in stages, which keeps each change small enough to attribute if something moves.
By looking at the store, the admin and the backlog rather than at the brief. The output is a named constraint and the smallest piece of work that removes it, which is sometimes smaller than the brief assumed and occasionally larger.
If the answer turns out to be a restructure rather than a redesign, we will say so before a design brief is written.
