Service
The storefront is the easy part.
E-commerce for companies whose catalogue, payments and fulfilment have outgrown the template. We build the storefront, then the half nobody demos — tax, stock, returns, failed payments and the sync between them. Peak trading is what that half is for.
The Problem
Where storefronts lose the order
The homepage is rarely the problem. Orders are lost further down: in search results nobody scrolls past, on a second payment attempt, and in the spreadsheet a merchandiser keeps because the platform will not hold their data.
- 01
The platform cannot hold the catalogue
Attribute-heavy products, variants the model was never sized for and per-market pricing sit outside the original schema. Merchandisers patch the gap by hand, and every range added makes the catalogue slower to browse.
- 02
Search is a text box, not merchandising
Default relevance ranks on text similarity alone. Margin, stock cover and season — the things a trading team actually decides on — have no way in, so the products you need to move stay buried.
- 03
Checkout fails quietly
Declines, tax rules, address mismatches and half-finished bank authentication all end the same way: no order, no error, no record of the attempt. Support hears about it before the dashboard does.
The Approach
Build the difficult half first
We start with the layers that decide whether an order completes — catalogue model, stock truth, payment and fulfilment contracts — then put a storefront on top. The front end is the cheapest layer to change later.
- 01
Headless when it earns it
Decoupling is a cost as well as a capability. We take it when content and merchandising are blocked behind release cycles, and keep a platform's native storefront when it is already doing the job.
- 02
One owner for stock and price
Product, price and stock data get a single source — often the ERP — and everything downstream reads from it. Two systems that both believe they are authoritative is how overselling starts.
- 03
Checkout as a state machine
Every failure path becomes a named state with a retry, a message and a log line: declined card, expired session, tax lookup timeout, partial capture. Nothing exits into silence.
Capabilities
What we build
Commerce work splits between the shop window and the operations behind it. These are the pieces we take on, as a whole programme or one at a time.
-
Headless storefronts
A commerce API behind a front end we control, with rendering chosen per template — static category pages, server-rendered search, client-side only where the interaction actually demands it.
-
Catalogue at scale
Product models that survive variants, bundles, per-market pricing and localisation, with bulk import and enrichment routes a merchandising team can run for itself.
-
Search and merchandising
Relevance tuned against the queries people actually type, plus facets, synonyms and boost rules a trader edits directly — by margin, by stock cover, by season.
-
Payments and checkout
Multiple providers, saved methods, strong customer authentication, partial captures, refunds and retries — plus a reconciliation view so finance can match a payout to the orders inside it.
-
Fulfilment and returns
Order routing across warehouses and drop-ship partners, carrier labels and tracking, and a returns flow that puts stock, refund and the accounting record back into agreement.
-
Storefront performance and SEO
Core Web Vitals treated as a build gate, with canonical and faceted-URL rules written deliberately so filter combinations stop competing against the category pages that should rank.
Technologies
What it runs on
Platform choice follows the catalogue, the market rules and whoever has to operate the thing afterwards. We will say plainly when the platform you are already on is the right one.
Commerce platforms
Storefront
Search and data
Payments, tax and shipping
How we work
From audit to peak trading
- Step 01
Trading audit
We walk the funnel with the merchandising and operations teams, then read what sits behind it: searches with no results, abandoned payments, returns reasons, the products support gets called about.
- Step 02
Catalogue and data model
Products, variants, pricing and stock are modelled first, along with which system owns each field. Migration and enrichment rules are written here, before anything is moved.
- Step 03
Payment and tax rules
Provider integration, tax and shipping logic, and every declined, timed-out or abandoned route handled on purpose. We test with failing cards and slow lookups, not only the happy path.
- Step 04
Storefront and merchandising
Templates, search, facets and content built on top of the model, then the merchandising controls handed over with the training to use them. The team that trades the site should own it.
- Step 05
Peak readiness and cutover
Load testing against realistic traffic shapes, a rehearsed cutover with a rollback route, then a watched trading period with alerting on orders, payments and stock sync.
Tell us where the orders stop
Send the catalogue size, the platform you are on and the part of the funnel that worries you. We will say whether that is a replatform or a fix.