E-commerce development for stores that sell on every device

Three decisions that outlive everything else

Most of what people call e-commerce development is assembly: templates, apps, payment methods, a theme. That part is not hard. What determines whether the store is a pleasure or a liability three years from now comes down to three decisions, all of which get made early and casually.

The first is the platform, because migrating away from one is a project in its own right. The second is the catalogue and URL structure, because restructuring it later is a redirect exercise with search consequences. The third is where the truth about stock and price lives, because if the answer is “both the store and the warehouse system”, you have signed up for a permanent reconciliation problem.

Everything else on this page is downstream of those three.

Platform selection, without the sales pitch

Shopify is the right default for most merchants, and saying so is not a lack of imagination. It removes hosting, PCI compliance, platform patching and checkout optimisation from your list entirely, and its checkout converts partly because a very large number of shoppers have completed it before and trust the shape of it. The constraints are equally real: the checkout is customisable only within the boundaries Shopify permits, transaction fees apply unless you use Shopify Payments, some app dependencies become surprisingly expensive at volume, and genuinely complex B2B rules push you toward Plus.

It is worth knowing that Shopify has moved checkout customisation onto an extension model. The old checkout.liquid layout is no longer supported for the information, shipping and payment steps, and was sunset for the thank-you and order-status pages in August 2025, with legacy script tags following for non-Plus stores in 2026. If your store still relies on checkout customisations built the old way, that is a migration you have already been given a deadline for.

WooCommerce gives you complete control, no platform transaction fee and the whole WordPress content ecosystem, which matters if content marketing is central to how you sell. In exchange, you own hosting, security, updates, plugin compatibility and performance. That is a fair trade when you have technical capability and a content-heavy strategy. It is a poor trade when nobody is accountable for maintenance, because the failure is gradual and invisible until it is not.

Adobe Commerce earns its complexity on large catalogues, multi-store setups, sophisticated B2B pricing and heavy ERP integration. It requires genuine specialist capacity to run well, and it is over-specified for most merchants who consider it.

BigCommerce sits between Shopify and the open platforms: hosted and maintained, with fewer app dependencies for features others charge for, and native B2B capability. It has a smaller ecosystem, which cuts both ways.

We assess against your catalogue size, variant complexity, tax and shipping rules, integration list, team capability and total operating cost rather than initial build cost. Then we write down what we rejected and why, so the decision remains open to challenge.

Catalogue structure is search architecture

The most common structural failure we find is not a design problem. It is a catalogue where the same product exists in several collections under slightly different names, variants are modelled as separate products, and filters generate a URL for every combination anyone has ever clicked.

That last one matters more than most merchants realise. Google’s guidance on faceted navigation is direct: crawlers cannot tell whether a filtered URL is useful without crawling it, so they access a very large number of them, and the time spent there is time not spent discovering new, useful URLs. On a large catalogue that is a genuine constraint on how quickly new products get indexed.

The fixes are decided at modelling time, not retrofitted. Decide which filter combinations deserve to be indexable landing pages — usually a small, commercially chosen set — and which should be blocked or canonicalised. Keep parameter order consistent so the same selection always produces the same URL. Return a proper 404 when a combination has no results rather than serving an empty page. And remember that rel="canonical" is a strong signal rather than a directive, so it consolidates duplicates but does not control crawling; robots directives and URL design do that.

Variants deserve the same deliberation. Whether size and colour are options on one product or separate products changes your URL count, your feed, your structured data and your reporting. It is a five-minute conversation before the import and a redirect project afterwards.

Product pages, collections and on-site search

A product page has one job: answer everything that stands between interest and purchase. In practice that means real photography at usable zoom levels, the specification detail your buyers actually compare, delivery cost and timing shown before the checkout rather than discovered inside it, stock status stated plainly, and a returns policy that does not require hunting.

Collection pages do the ranking work and the merchandising work at once. They need enough editorial content to be a genuine answer to a category-level query, filters that are fast and do not reload the world, and a default sort order chosen commercially rather than left at whatever the platform installed.

On-site search is consistently the most underrated surface in a store. Visitors who search convert at a different rate from visitors who browse, and a search box returning nothing for a common misspelling is a losing transaction you never see. A dedicated engine such as Algolia, or Shopify’s own search and discovery tooling, gives you typo tolerance, synonyms, merchandising rules and — importantly — a report of what people searched for and did not find. That report is a product development brief you already own.

Checkout, payments and fraud

Checkout is where every earlier decision either pays off or does not. The fundamentals are unremarkable and consistently ignored: guest checkout available without an argument, form fields with correct autocomplete attributes and input types, address entry that tolerates real addresses, wallets offered early rather than after manual entry, all costs shown before the final step, and errors shown next to the field that caused them rather than as a banner at the top.

On payments, our position is fixed. Card data never touches code we write. Capture happens inside the provider’s hosted fields or the platform’s native checkout, whether that is Stripe, PayPal, Razorpay or the platform’s own. That keeps your PCI DSS scope as small as it can be, and PCI DSS applies to any organisation that stores, processes or transmits cardholder data, which includes merchants. Any proposal that involves handling raw card numbers to improve the experience should be turned down, including one from us.

Fraud settings need calibration against your basket profile rather than acceptance at default. Rules tight enough to stop chargebacks on high-value goods will decline legitimate customers on a low-value catalogue, and false declines are expensive precisely because nobody complains about them — the customer simply leaves.

Performance on the templates that actually sell

Homepage performance is the metric everyone measures and the one that matters least. The pages under load are collection and product pages, usually on a phone, often on a connection nothing like the office.

The Core Web Vitals thresholds are the shared vocabulary: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, Cumulative Layout Shift at or below 0.1, each assessed at the 75th percentile of real visits. Stores fail these for a predictable set of reasons. Product images shipped far larger than displayed. A filter interaction that blocks the main thread. Layout shifting as prices, badges or review widgets load in. And apps — the accumulated scripts of a review tool, a chat widget, three marketing tags and an upsell popup, each adding weight nobody attributed to it.

The practical discipline is an app and tag audit with a named owner, images served responsively in modern formats, third-party scripts loaded late or not at all, and field data monitored rather than trusting a lab score from a fast machine. Where the store is genuinely constrained by the theme layer, that is one of the few honest arguments for going headless.

Headless commerce: when it is actually worth it

Headless separates the storefront from the commerce engine, so the front-end is yours to build in Next.js, Hydrogen or anything else that talks to the platform’s API. It is a real capability and it is chosen for the wrong reasons more often than any other decision in this field.

Good reasons: an experience the theme layer genuinely cannot express, such as a complex configurator or a heavily editorial buying journey; several storefronts or brands sharing one catalogue and one inventory; content that must come from a CMS the platform cannot serve; or performance requirements the theme layer has demonstrably failed to meet after real optimisation work.

Poor reasons: it is faster by default — it is not, unless you make it so; competitors are doing it; a proposal said the word “composable”.

The cost is ownership. In a themed store, the platform maintains rendering, caching, previews, search behaviour, accessibility defaults and checkout integration. Go headless and every one of those becomes yours, permanently. The Shopify Storefront API is GraphQL-only and genuinely good, and the build is tractable — the question is whether you want the maintenance obligation for the next several years, not whether the first version can be delivered.

Integrations: stock, orders and the systems that hold the truth

Every store of any size talks to something else: an ERP, a warehouse system, a fulfilment provider, an accounting package, a CRM, a shipping aggregator, an email platform such as Klaviyo, and often a tax service such as Avalara.

The design principle is single ownership per field. Stock belongs to the warehouse system. Price frequently belongs to the ERP. Customer records may belong to the CRM. Writing that down prevents the nightly loop where two systems overwrite each other and someone starts checking manually.

Then build defensively: webhook-driven updates rather than polling where the platform supports it, retries with backoff, idempotency keys so a repeated message cannot duplicate an order, and a visible failure queue with an owner. Silent integration failure is worse than loud failure, because the store keeps selling something you cannot ship.

Technical SEO and measurement

Store SEO has a few build-side obligations that are hard to add later. One canonical URL per product with consistent internal linking. Pagination handled so paginated results are crawlable. Product structured data that matches what is visible — price, availability, and reviews only where reviews genuinely exist on the page. A Merchant Center feed mapped to the required attributes so paid and free listings pull from a controlled source rather than a scrape. Beyond the build, the ongoing work of category content, keyword coverage and competitive positioning belongs with e-commerce SEO.

Measurement deserves the same rigour. GA4 e-commerce events implemented through Google Tag Manager, consent handling in place before launch rather than after a complaint, and a written definition of each event so marketing and finance are describing the same thing. Attribution will still be imperfect — consent choices, cross-device journeys and privacy protections mean platform-reported figures and your order table will not reconcile exactly. Anyone claiming otherwise is selling a dashboard. What you can have is a consistent, documented method, which is what makes paid campaigns measurable in the first place.

Replatforming without losing what you already earn

Replatforming is the highest-risk project in this field, and the risk is concentrated in a single artefact: the redirect map.

We export every indexable URL from the current store, cross-reference against Search Console and analytics to identify what actually earns traffic, revenue and links, and map each one individually. Not by regex pattern. Patterns handle ninety per cent and quietly drop the category page that generated a quarter of your organic revenue. Google recommends permanent 301 or 308 redirects, advises keeping them in place for at least a year, and confirms that permanent redirects do not cause a loss in PageRank — so when traffic disappears after a migration, the cause is nearly always an unmapped URL, content shortened during the rebuild, or a slower new store.

Two further habits matter. Preserve the content that ranks rather than replacing it with terser template copy, because thinner pages rank worse regardless of how much better the platform is. And expect a settling period: Google states that a small to medium site can take a few weeks for most pages to move across, and larger sites longer. Planning for that is different from panicking through it. Anything that needs deeper diagnosis afterwards is technical SEO work rather than development work.

Launch, and the part after

A store launch should be rehearsed. Tracking verified against test transactions, structured data validated, the redirect map applied on staging and checked link by link, payment methods exercised including the declines, and monitoring live before DNS changes rather than after.

Afterwards, the technical layer needs a named owner: platform and app updates, theme compatibility, performance against the agreed budget, integration health and security patching. Merchandising belongs with your team, and we build and document the store so that is genuinely true — adding a product, building a collection or running a promotion should never require us.

What makes a build cost more or less

No figures here, because the drivers vary enough that a headline number would be fiction. What genuinely moves it: catalogue complexity and variant structure; whether pricing is uniform or account-specific; the number and maturity of integrations, where one undocumented legacy system can cost more than several modern ones combined; how much checkout customisation is needed beyond platform defaults; the number of payment methods, currencies, languages and tax jurisdictions; whether B2B ordering is required; and whether an existing store is being migrated with its data and its URLs.

The two costs merchants underestimate are data migration from a messy catalogue and the content work that a good store needs — product copy, photography, category descriptions. Both are slow, both resist automation, and both are usually discovered halfway through.

Adjacent work

A store rarely exists on its own. The non-commerce parts of the site — the content, the brand pages, the landing pages — are ordinary web development work. If the storefront needs designing rather than adapting from a theme, that starts with web design, and where the buying journey itself is the problem, interface and experience design is the right lens. Once it is live, the growth work splits between organic visibility and paid acquisition, and the two should be planned against the same measurement model rather than reporting separately.

If you are weighing a replatform, ask us to look at your current URLs first — that is usually the fastest way to find out how risky the move actually is.