E-Commerce: The Stages of a Solution
Most e-commerce projects fail at a stage transition, not at launch. The four stages a commerce system passes through, and the signals that tell you it is time to move.
The short version
- Commerce systems pass through four recognisable stages. The expensive mistakes are building for a stage you are not at.
- Stage transitions, not launches, are where projects fail — usually because the previous stage’s assumptions were never written down.
- Order management, not the storefront, is what eventually determines whether the business scales.
- Move stage when a specific constraint is costing you money, not when a competitor announces something.
An e-commerce build is rarely one project. It is a sequence of systems, each of which was correct at the time and each of which is eventually outgrown. Knowing which stage you are in tells you what to build next and, more usefully, what to refuse to build yet.
Stage 1: the hosted storefront
Shopify, WooCommerce, or a similar platform, configured rather than built. A theme, a product catalogue, a payment provider, live in weeks.
What it gets right. Speed to market, near-zero infrastructure work, PCI compliance handled, and a proven checkout that converts. The checkout matters more than teams expect: platform checkouts have been optimised against enormous volumes of real behaviour, and a custom one almost always converts worse initially.
What eventually constrains you. Data models you cannot extend. Checkout logic you cannot alter. Integrations limited to what the app marketplace offers. Per-transaction fees that grow with success. And the fundamental one: your business logic must be expressible in the platform’s vocabulary.
Signals to move on. You are paying for apps that partially solve problems. Your operations team maintains spreadsheets to compensate for something the platform will not model. A product configuration your customers genuinely want is not representable.
Stay here longer than feels comfortable. The most common expensive error in e-commerce is leaving stage one because the platform feels limiting rather than because a specific limitation is measurably costing money. “We’ve outgrown Shopify” is a claim that should come with a number attached.
Stage 2: the extended platform
Still on the platform, but with meaningful custom work around it. A headless storefront using the platform’s APIs, custom apps for specific logic, and integrations into an ERP or fulfilment system.
What it gets right. You keep the checkout, the compliance and the operational maturity while getting a frontend you fully control and business logic that lives in your own code. For a large majority of merchants this is the terminal stage and there is nothing wrong with that.
What it costs. Two systems to reason about instead of one. Platform API rate limits become a real constraint. Upgrades can break your customisations. And the boundary between what lives in the platform and what lives in your code needs active governance, because without it the answer becomes “both, inconsistently”.
Signals to move on. The platform is now mostly a database and a checkout you wrap. Rate limits shape your architecture. You are fighting the platform’s order model on a weekly basis.
Stage 3: composable commerce
Best-of-breed services assembled behind your own application: a commerce engine for catalogue and cart, a separate payment provider, a search service, a CMS, a tax engine, an order management system.
What it gets right. Each capability is chosen on its merits and replaceable independently. Search can be excellent without waiting for a platform roadmap. You can serve B2B and B2C from one system with genuinely different rules.
What it costs. Substantially more, in ways that are easy to underestimate. Integration is now a permanent, ongoing job rather than a project. Every service has its own data model, and reconciling them is your problem. Failures are distributed and harder to diagnose. Total vendor spend usually exceeds what the single platform cost.
Signals you are ready. Revenue supports a dedicated commerce engineering team. You have specific requirements no single platform serves. Multiple brands, regions or channels need genuinely different behaviour over shared inventory.
Stage 4: the custom platform
Core commerce logic built in-house because it is the business. Rare, and correct for a small number of companies: marketplaces with unusual economics, subscription models nothing off the shelf represents, businesses whose pricing or fulfilment logic is genuinely their competitive advantage.
The honest test is whether your commerce logic is a differentiator or a cost centre. If a competitor could copy your checkout and take nothing valuable, it is a cost centre and should be bought.
What actually determines whether you scale
Teams plan e-commerce projects around the storefront, because that is what everyone can see. The systems that determine whether the business scales are behind it.
Order management
The single most underestimated component. An order is not a row that transitions from paid to shipped. It is split across warehouses, partially fulfilled, partially refunded, exchanged, backordered, cancelled after picking. Every one of those is a state your model must represent, and retrofitting them into a model that assumed a linear lifecycle is one of the more painful projects in commerce engineering.
Model orders as a sequence of immutable events with derived current state, rather than as a mutable record with a status column. It costs more initially and it is the difference between adding partial refunds in a day and rewriting the order subsystem.
Inventory
Inventory is where oversells come from, and oversells cost you customers rather than just money. The distinctions that matter: on hand versus available versus reserved. A cart holds a reservation; a reservation expires; an expired reservation returns stock. Multiple warehouses multiply this. Get the reservation model right early, because every downstream system depends on it.
Search and merchandising
On-site search drives a disproportionate share of revenue, because a searching customer has already decided to buy something. Database LIKE queries are not search. Typo tolerance, synonyms, faceting and merchandising control are the baseline, and this is a solved problem worth buying rather than building.
Tax
Tax is more complicated than any engineer expects, and it gets worse with every jurisdiction. Rates vary by product category and by destination, with thresholds that change. This is a compliance obligation, not a calculation. Buy a tax engine.
Performance is revenue
The relationship between page speed and conversion in e-commerce is one of the better-evidenced findings in the field. The specifics vary by study; the direction never does.
The high-leverage work, roughly in order:
- Product images, which dominate page weight. Modern formats, correct dimensions, lazy loading below the fold.
- The critical rendering path on product and category pages, which are where most sessions land.
- Checkout, where every additional step and every unnecessary field costs completions.
- Mobile specifically, which is where most traffic and the worst measurements are.
Boolean Solutions experience with commerce
We have built at every one of these stages and migrated between them. The advice we most often give is to stay put — the constraint the team is frustrated by is frequently solvable within the current stage for a fraction of the cost of moving.
When the move is genuinely warranted, the work that determines success is order management and inventory, not the storefront. Those are also the parts that get scoped last. If you are planning a commerce build or a replatform, get in touch and we will give you an honest read on which stage you actually need.
Further reading
- Baymard Institute research — the most rigorous body of e-commerce UX research available, particularly on checkout abandonment
- MACH Alliance — the composable commerce position, worth reading critically
- The Usefulness of a Payment System — the payment layer in detail
- Caching Layers — where the page speed above actually comes from
Udit Mittal
Founder at Boolean Solutions. Twenty years of building and rescuing web, mobile and AI products for SaaS companies and startups — and writing down what actually worked.
Get in touch
