Planning an ecommerce website that can grow

A store can outgrow its first build when the catalogue, pricing rules or integrations become harder to manage. Changing the platform alone will not resolve unclear requirements. Start by documenting the products, buying process and operations the website needs to support.

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

Write down the actual promotion and fulfilment rules. Illustrative cases include trade-customer discounts, clearance exclusions, shipping thresholds, bulky-item charges and customer-specific tax handling. They are requirements to verify with the business, not assumptions about every store.

Write every rule down before the build. Then check whether the platform expresses them natively, needs an app, or needs custom code. That document lets you compare the cost and complexity of the available approaches before committing to a build.

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 consider all three approaches. Product count alone does not settle the choice: variants, regional requirements, integration needs and the team maintaining the store also matter. If you want the detail on either, our ecommerce development page sets out how we scope them.

Search and filtering for a growing catalogue

As the catalogue grows, check whether customers can find products using the words and attributes they know. Test the store’s existing search with common queries, misspellings and product comparisons before deciding whether another search service is needed.

Search tools can add synonyms, tolerant matching and useful filters, but they also need configuration and maintenance. Track searches returning nothing and review the wording against the catalogue. A missing result may mean a synonym is absent, an item is hard to find or the customer expects something you do not stock. Investigate before treating it as demand for a new product.

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. Extra steps and slow validation can make checkout harder. Review errors, completion rates and customer feedback before attributing a sales change to a performance improvement.

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

Avoid adding headless architecture, a custom checkout or several overlapping apps without a requirement that justifies them. Review catalogue size, supported checkout options and operational needs. Choose the launch window against trading risk, data migration and the support available; a peak period may call for postponing a move.

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.

This sequence makes the important decisions visible before the build becomes expensive to change. 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.