Building an ecommerce site that scales past the first big month

We have rebuilt eight stores in the past three years that had outgrown their first build. Not one of them failed because of the platform. They failed on decisions made before the platform was chosen, and then encoded into it.

This is the order we work in now.

Model the catalogue first

This is the decision you cannot cheaply reverse, and it is routinely made in the first week by whoever is loading the products.

Work out what a product actually is in your business. Is a colour a variant of one product or a separate product? Does a size affect price, weight, tax treatment or shipping class? Do you sell bundles, and is a bundle a product or a rule? Do you have products that exist only as part of another product?

Get this wrong and every later problem inherits it: search results duplicate, stock counts drift, the feed to shopping channels is wrong, and reporting cannot answer simple questions.

The exercise we run: take fifty real products including all your awkward cases, model them on paper, and check the model answers ten questions the business actually asks. Best-selling colour. Stock by size. Margin by bundle. If it cannot, the model is wrong, and it is far cheaper to find that out on paper.

Write down the promotional rules

The second most common failure. Every store has promotional logic living in someone's head: trade customers get 15% except on clearance, free shipping over a threshold that excludes bulky items, a discount that stacks with one thing but not another, tax handling that differs by customer type.

Write every rule down before the build. Then check whether the platform expresses them natively, needs an app, or needs custom code. This one document has saved more budget on our projects than any technical decision we have made.

Where the rules are genuinely complex, B2B pricing tiers, contract pricing, quantity breaks that interact, build for it deliberately rather than discovering it in month two with the catalogue already loaded.

Then choose the platform

With the catalogue and the promotional rules written down, the platform question usually answers itself.

Shopify suits a conventional catalogue, standard promotions and a small team, where speed to launch matters and the app ecosystem covers the gaps. The cost is the theme layer's performance ceiling and the accumulating app subscriptions.

WooCommerce suits stores already living inside a WordPress content operation, with moderate catalogues and a need to customise behaviour cheaply. It needs real hosting and real maintenance, and it degrades badly when neglected.

A custom or headless build earns its cost when the catalogue is unusual, the promotional logic is genuinely complex, the integration surface is large, or performance is a competitive factor. It is the wrong answer for a first store with 200 products.

We build on all three, so the honest answer is that most businesses under about a thousand products are well served by the first two. If you want the detail on either, our ecommerce development page sets out how we scope them.

Search and filtering above 500 products

Once a catalogue passes a few hundred items, on-site search becomes the main navigation, and default platform search is usually poor: no synonyms, no typo tolerance, no useful ranking.

A proper search service with synonyms, tolerant matching and filter facets consistently pays for itself. Track the searches returning nothing. It is the cheapest product development signal you will ever get, and most stores never look at it. On one homeware store, the top no-result term for three months was a product category the client had decided not to stock. They stocked it.

Performance is a revenue line

On the storefront the same rules apply as anywhere: largest image in the server-rendered HTML with a priority hint, one interactive island per section, fonts self-hosted and subset, third parties after consent. The measured version of all four is in what actually moves Core Web Vitals.

Ecommerce adds two of its own. First, app and script accumulation: six apps each adding a script is the most common cause of a slow Shopify store, and the fix is auditing what each one costs in milliseconds and deleting the ones nobody can justify. Second, the checkout. Every extra step and every slow validation call costs orders directly, and it is the one place where a fraction of a second is measurable in money.

Plan the integrations before launch

List every system the store must talk to: accounting, inventory, shipping, ERP, marketplace feeds, email platform, review platform. For each, decide whether it is real-time or batch, who owns the failure when it breaks, and what happens to an order stuck in between.

Stores that grow well have this written down. Stores that break have it discovered, usually at 6pm on the first busy Friday.

What we would not do

Go headless for a 200-product store. Build a custom checkout on a platform that provides one. Install eleven apps that each solve a small problem and collectively make the store slow. Launch without a stock reconciliation process. And migrate during a peak trading period, which we have been asked to do and have declined more than once.

A sensible sequence

Catalogue model, promotional rules, integration list, platform choice, build, search, performance pass, then a soft launch with real orders before the marketing spend starts.

That order costs less than any alternative we have watched people try. If you are replatforming rather than starting fresh, the redirect map and the category structure decide whether you keep your rankings, which is a website redesign problem as much as a commerce one, and worth involving someone in before the new catalogue is finalised.