One flow, from first view to a counted order
- Discovery
view_item_listStructured - Product
view_itemVerified - Cart
add_to_cartTracked - Checkout
begin_checkoutRouted - Measurement
purchaseMeasured
05 / Capabilities
Commerce
Online stores designed around the catalogue and the checkout, and engineered to survive a real operations team.
Part of — 03 Build
What it is
Commerce work covers the storefront, the product experience and the checkout, plus the integrations that keep stock, pricing, tax and fulfilment correct. It is as much an operations problem as a design one.
The mechanism
From discovery to a measured order.
A store is a flow a buyer moves through and a catalogue the business runs behind it. Both are designed together, so the page never promises what stock, price or tax rules cannot deliver.
The system of record, kept in step
- Products
PIMConnected - Stock
inventoryMonitored - Prices
price rulesVerified - Tax
tax rulesVerified - Orders
order handoffRouted
Ordered by the objections a buyer has
Product page
- Is it right?
- Fit
- Specification
- Can I trust it?
- Evidence
- Returns
- Is it worth it?
- Price
- Delivery
Who it is for
- Brands whose store looks like the platform template it was built on
- Retailers whose catalogue structure no longer matches how people shop
- Teams losing orders in the gap between the storefront and the back office
What usually breaks
- The product page answers the questions the catalogue has, not the ones the buyer has.
- Checkout adds friction the brand never chose: forced accounts, surprise costs, dead ends.
- Stock and pricing disagree between the store and the system of record.
What we change
01
Start at the product page
It is the page that carries the decision. We design it first and let the rest of the store follow from what it needs.
02
Checkout is a design surface
Every removable step is removed. What remains is explained in plain language, including cost, delivery and returns, before the payment step.
03
Integrations decide reliability
Stock, pricing, tax and fulfilment are mapped as contracts with defined failure behaviour, not as a hopeful sync.
Deliverables
- Catalogue and taxonomy model
- Product, collection, cart and checkout experience design
- Storefront implementation on the chosen platform
- Integration map: inventory, pricing, tax, shipping, fulfilment
- Commerce event tracking aligned with the analytics taxonomy
What it does not do
- We do not take responsibility for stock accuracy, pricing decisions or delivery promises. We make them visible and correct in the storefront.
- A better storefront does not fix a product, a price or a delivery promise the market has already judged.
- We do not migrate a platform without a rollback plan and a rehearsal of it.
Process
01
Catalogue audit
How the range is actually structured, and how people actually search it.
02
Journey design
Discovery, product, cart, checkout and post-purchase, designed as one path.
03
Build and integrate
Storefront, platform configuration and the integrations, with failure states handled.
04
Instrument and hand over
Commerce events, dashboards and an operations runbook.
Questions
Which commerce platforms do you work with?
We work with established platforms — typically Shopify for direct-to-consumer, or a headless setup where the catalogue and the content need to move independently. We choose based on the operations team, not on preference.
Can you rebuild the storefront without replatforming?
Often, yes. If the platform is sound and only the storefront is the problem, a custom storefront on the same commerce engine is faster, cheaper and far less risky than a migration.
Do you handle the operational side after launch?
We hand over a runbook and stay available for a defined support period. Ongoing operations are scoped separately, honestly, and only where we can genuinely add something.
—Start
Have a system worth building?
Tell us what the business needs to do. We will tell you what it takes to build it, and what it takes to keep it running.