What an online store redesign really costs

An invoice says design and development, but most of the hours land somewhere less photogenic. Discovery and inventory come first: how many distinct templates exist, how many product types, which plugins render on customer-facing pages. Then design of a system rather than a set of pages — typography, spacing, component states — because a shop needs a grid, a filter, a variation picker and a cart, and every one of those has an empty, loading and error state. Then the frontend build, ideally against your real catalogue rather than placeholder data. Then the unglamorous half of the budget: URL and redirect mapping, analytics and tag parity, structured data, QA across browsers and payment paths, and a launch plan you can reverse. When a quote looks surprisingly cheap, it is almost always one of those last items that has quietly gone missing.

The spread between quotes comes from a small set of variables, and none of them is the homepage. Catalogue size matters less than catalogue shape: twenty thousand simple products is an easier job than four hundred configurable ones with per-variation imagery and stock rules. Template count is the real unit of work, so a store with one product layout is a different engagement from one carrying bundles, subscriptions and a made-to-order flow. Integrations are the quiet multiplier — an ERP sync, a review platform, a loyalty programme, a tax engine — each of which has to keep functioning on the new storefront. Content is nearly always underestimated: fresh layouts expose thin category copy and missing photography that somebody has to produce. Multilingual and B2B pricing rules add a dimension to every template, which is why they never cost a bit more; they cost a tier more.

• Number of distinct templates, not number of pages
• Product complexity: variations, bundles, subscriptions, made-to-order
• Integrations that must survive the move: ERP, reviews, loyalty, tax
• Extra dimensions: multilingual, B2B tiers, customer-specific catalogues

Most briefs collapse into three shapes, and naming yours is half the budgeting exercise. A fix is targeted work: image handling, script cleanup, a repaired mobile navigation, one broken template. It is measured in days and sits in the low four figures because nothing structural changes. A restyle keeps the existing theme and rebuilds the surface — a new visual system, reworked category and product layouts, a tidied cart — and in the ranges we commonly see it runs from the mid four figures into the low five, depending mostly on template count. A rebuild replaces the storefront layer outright, which is the point where redirect mapping, analytics parity and a genuine QA cycle stop being optional; those commonly start in the low five figures and climb through the mid five figures once migrations, integrations and content rework are included. Paying rebuild prices for a fix-tier problem is the most common way to waste a redesign budget.

A cheap quote is rarely a discount. It is usually a smaller scope wearing the same words, and the first things to disappear are the ones a buyer cannot see in a mockup. With no URL and redirect map, a launch quietly retires ranking pages and the traffic loss surfaces six weeks later as a marketing problem nobody can explain. With no analytics and tag parity, you lose the ability to prove the new site is better — and comparing an old measurement setup against a new one that fires different events is worse than having no data at all. With no QA pass across real payment methods, shipping zones and tax cases, the broken combination gets found by a customer. Adding any of this after launch costs more than including it, because now you are debugging live revenue under time pressure. Our notes on an SEO-safe redesign cover what that mapping involves.

• No redirect map: old URLs 404 and rankings reset quietly
• No analytics parity: you cannot tell whether it worked
• No QA matrix: payment, shipping and tax edge cases fail in production
• No rollback plan: a bad launch stays bad until it is rebuilt

A redesign is not a one-off purchase, and a budget that stops on launch day is an incomplete budget. Hosting and build infrastructure for a modern frontend is a running line item — usually modest, but real. Somebody has to keep the design system fed with new categories, seasonal landing pages and photography that matches the new layouts. WordPress, WooCommerce and the plugins that render on the storefront keep updating, and each update is a small compatibility question. Then there is the support tail: the first two months after launch always produce fixes, because real traffic finds cases no test plan imagined. Ask any prospective partner what happens in weeks two through eight and what it costs. A proposal that treats launch as the finish line is describing the moment your risk is highest, not lowest.

On a WooCommerce store the cheapest redesigns are the ones that leave business logic alone. Products, stock, orders, coupons, tax and shipping rules, payment gateways and the admin your team already knows do not need rebuilding for shoppers to get a faster storefront — and rebuilding them is exactly where budgets vanish. What changes is the customer-facing layer: category and product templates, search and filtering, the cart, and how quickly pages reach a phone against Google's Core Web Vitals thresholds. Checkout can stay native WooCommerce, so payment and tax plugins behave as they do today. Baymard Institute's checkout research is a strong argument for simplifying that flow, but simplification is a design decision, not a reason to replace a payment stack that already works. Writing this boundary into the proposal before you sign is the most reliable way to keep a quote honest.

Sometimes the right recommendation is not to redesign yet. If the store sees a few hundred sessions a month, no layout fixes that arithmetic; the constraint is acquisition, and a redesign spends the budget that would have bought traffic. If drop-off traces back to price, stock availability or delivery cost, the storefront is not the bottleneck and a new one will not move the number. If the site is simply slow, a targeted speed pass usually recovers most of the experience for a fraction of a rebuild: image formats and sizing, script discipline, caching, a plugin audit. On a small budget the sensible order is to measure first, repair the two worst templates, and rewrite the category and product copy you already own. None of that is wasted if you rebuild later — it is the same content and the same baseline, moved onto a better foundation. A short audit costs far less than learning the answer at rebuild scale.

Comparing proposals on the total alone is how buyers end up with the expensive cheap option. Normalise them first: ask each side for the template list they are pricing against, who is producing content and photography, whether redirects and analytics parity are in scope, what the QA matrix covers, and how long post-launch support runs. Two numbers that look far apart usually converge once the missing items are added back to the lower one. At NextWoo, engagements start at $1,999, and what sits above that depends on template count, integrations, and whether content and migrations are ours or yours. We scope by inventory rather than by page count, and we say plainly when the tier you asked for is bigger than the problem you have. The pricing page shows how the packages are shaped.

• Ask for the template list each quote is priced against
• Confirm who owns content, copy and photography
• Check redirects, analytics parity and QA are named line items
• Compare the post-launch window, not only the launch price