Commerce platforms, built for the order that comes back.
Catalogue, inventory and checkout engineered alongside returns and settlement, because the reverse path is where retail margin is actually decided and it is the half most platforms treat as an afterthought. Ten commerce platforms already in production, and a custom engineering team for everything beyond them.
Custom build - 2 to 8 weeks, scoped
Ready-made platform - 6 working days
Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our facts page.
What a commerce build actually contains
The sequence below is where commerce platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it.
Retail has a structural asymmetry that shapes every build. The forward path - browse, add to basket, pay - is well understood and every platform does it adequately. The reverse path is where the money goes: a returned item has to be received, inspected, restocked or written off, and refunded against a payment that may have been split across a card, a voucher and a loyalty balance. Apparel operators routinely see a quarter or more of units come back, and a platform that treats returns as an exception flow will bleed margin quietly for years.
Three of the seven phases have no shortcut. What a shipped platform removes is the middle: inventory and order management, checkout, and fulfilment integration.
Catalogue, taxonomy and search
A product is not a row. It is a family of variants across size, colour and configuration, each with its own stock, price and sometimes its own regulatory status. Fashion needs size grids that differ by brand and region. Electronics need compatibility relationships. Grocery needs weight-based units. A schema that models one of these well and the others badly limits which categories you can add later.
Search is the other half and it is a conversion problem, not a technical nicety. Most commerce revenue moves through search and filters rather than browsing, which makes attribute quality the constraint. If your data does not carry the attributes people filter on, no amount of search engineering recovers it.
The output is a catalogue model and an attribute standard your merchandising team can extend without a release.
Inventory, orders and the oversell problem
Stock is a shared resource under contention, and every commerce platform eventually oversells something. The question is whether it happens because you chose to accept the risk or because nobody modelled it. Reserving stock at basket, at checkout or only at payment are three different trade-offs between conversion and disappointment, and the right answer differs by category and margin.
The problem multiplies when stock sits in more than one place. A retailer selling from a warehouse, three stores and a marketplace listing has four systems with an opinion about availability, and reconciliation lag is measured in minutes that matter.
Orders need the same discipline as any state machine: partial shipments, backorders, cancellations before dispatch, and every transition idempotent because carriers and payment providers both retry.
Checkout, payments and fraud
Checkout is the highest-value surface in the business and the one most damaged by well-intentioned additions. Every field, every redirect and every unexpected cost added late reduces completion. The engineering job is to make the necessary steps fast and the optional ones invisible.
Payment mix is regional and non-negotiable: cards dominate some markets, wallets and bank transfer others, cash on delivery remains significant in several, and buy-now-pay-later has its own settlement and refund behaviour. Each adds a reconciliation path.
Fraud controls sit here as a tuning problem rather than a switch. Too loose and you carry chargebacks; too tight and you decline good customers silently, which is the more expensive failure because nobody complains about an order they were never allowed to place.
Fulfilment and the returns loop
Fulfilment is an integration problem: warehouse systems, carriers, tracking updates that arrive late or not at all, and a customer expectation set by the largest retailer they have ever used. Delivery promises should be computed from real capability rather than declared, because a missed promise costs more than a slower one honestly stated.
Returns are the phase teams under-build and the one that decides margin. A return has to be authorized, transported, received, inspected, and then either restocked, refurbished or written off, with the refund computed against a payment that may have been split across instruments. Each of those steps is a state, and the money is not final until inspection completes.
Build this properly and returns become a measurable cost you can manage. Build it as an exception and it becomes an unmeasured one.
Seller onboarding and marketplace operations
If you run a marketplace, sellers are your supply and their quality is your reputation. Onboarding needs identity and bank verification, catalogue ingestion in whatever shape sellers can produce, and a review queue for the listings that need a human look.
Seller payouts carry the same obligations as any split-money model: statements that reconcile, commissions computed from records, and reserves held against returns that have not happened yet. A marketplace that pays out before its return window closes has lent money without deciding to.
Counterfeit and prohibited-item handling belongs here, because it is a legal exposure rather than a policy preference.
Sale events and peak performance
Retail traffic is not smooth. A sale event, a campaign or a seasonal peak concentrates a month of demand into hours, and it concentrates it on a small number of products, which is worse: the load lands on the same catalogue pages, the same stock records and the same checkout path.
Sizing for this means caching aggressively where correctness allows and being explicit where it does not, because stock is exactly the number you cannot serve stale. Defined degradation matters: which features shed first, and whether a customer sees a queue or an error.
Launch and day two
A soft launch against a real catalogue, with real fulfilment, before demand spend begins. The first hundred orders teach you more about your operation than any amount of testing, particularly about the parts that involve physical goods and other companies.
Day two here is the first full returns cycle, which lags the first orders by weeks and is the moment the reverse path is genuinely tested. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want any of these phases costed against your catalogue and return rate?
Book a technical callWhere an order actually goes, and comes back
Every commerce platform is this loop with different names on the boxes. The forward path is well understood. What separates a platform with defensible margin from one without is whether the return path was designed at the same time.
Refunding on receipt rather than on inspection is the most common expensive shortcut in this sector. It feels generous and it means you refund items that arrive damaged, incomplete or not the item you sent, with no record to dispute against.
Why a refund is not the reverse of a payment
The intuitive model is symmetry: money came in, money goes back. It breaks immediately in practice. The original payment may have been split across a card, a stored balance, a voucher and a loyalty deduction, and each of those has different rules about what can be returned to it. A voucher that has expired cannot be reinstated. Loyalty points spent on a returned item may or may not come back depending on your own terms.
Then there is timing. Card refunds settle on the processor's schedule, not yours, so the customer's experience of "refunded" and your ledger's view of it differ by days. A platform that models the refund as a first-class object with its own states can answer where the money is. One that treats it as a negative order cannot, and the support burden lands on people who have to guess.
Want your returns and refund model reviewed against your actual return rate?
Talk to an engineerEight operators, eight different builds
"E-commerce" is not one buyer. The catalogue shape, the return rate and the settlement model change completely between them.
Multi-seller marketplaces
Supply is other people's businesses. Seller onboarding, payout reserves and listing quality are the product, and counterfeit exposure is a legal matter rather than a policy one.
4 shipped platforms
Direct-to-consumer brands
One catalogue, full control, and margin that depends on repeat purchase. Simpler operationally, but the platform has to carry brand experience rather than just transact.
3 shipped platforms
Fashion and apparel
The highest return rates in retail, size grids that differ per brand, and a reverse path that dominates the operating model. Returns tooling is not optional here.
2 shipped platforms
B2B and wholesale
Account pricing, credit terms, purchase orders and approval chains. The checkout most consumer platforms optimize barely exists; the quotation flow they lack is central.
2 shipped platforms
Cross-border commerce
Duties, customs documentation, restricted goods per destination and currency exposure between order and settlement. Landed cost shown honestly at checkout is the differentiator.
2 shipped platforms
Social and live commerce
Discovery happens outside your platform and demand arrives in bursts tied to a moment. Inventory accuracy under sudden concentrated load is the whole engineering problem.
1 shipped platform
Omnichannel retail
Stores and online sharing one stock pool, with collection, in-store returns of online orders and staff-assisted selling. Stock accuracy across locations is the hard part.
Custom build
Subscription and replenishment
Recurring boxes or auto-replenishment, where the product is the schedule. Skip, swap and pause logic drive retention more than catalogue depth.
Custom build
Six of the eight can start from something already running. Two are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years.
Not sure which of these you are, or you sit across two of them?
Book a scoping callHow the work actually runs
Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen.
Scoping against your catalogue and return rate
We start from what you sell, how much of it comes back, and where stock physically sits, because those three decide the architecture before any preference does. An apparel operator with a thirty percent return rate and an electronics seller with three percent need different platforms, and building the wrong one is expensive to correct.
Architecture and the money model
Stock reservation policy, payment instrument handling and refund states are designed before features are built, because all three are cross-cutting. Refunds become first-class objects with their own lifecycle rather than negative orders, which is the difference between being able to answer where a customer's money is and guessing.
Build against sale-shaped data
Commerce platforms fail on concentration and on stale stock, so test environments carry the shapes that matter: a sale event landing on twenty products, split-instrument payments, short picks, carrier updates arriving days late, and returns against orders that were already partially refunded. Evenly distributed test traffic proves nothing.
Length varies by trackPayments, fraud and compliance validation
Card data tokenized at the boundary so PCI scope stays small, fraud rules tuned against your own decline tolerance, and consumer-protection obligations checked per market. Our platforms arrive with a VAPT and compliance document, so external review starts from a documented baseline.
Fulfilment integration and pilot orders
Real orders through real warehouses and real carriers before demand spend begins. This stage depends on third parties more than any other, and it is where delivery promises meet actual capability rather than a service level in a contract.
Launch and the first returns cycle
Soft launch, then open, with the first complete returns cycle watched closely because it lags the first orders by weeks and is the only honest test of the reverse path. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want this sequence mapped against your catalogue and fulfilment model?
Book a technical callTen commerce platforms already in production
Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build.
They fall into three groups, and which group you start from matters more than which name you recognise. Horizontal marketplaces carry seller onboarding, payout reserves and listing review, which is most of the operational surface. Category retail platforms carry deep catalogue structure and, in fashion, the return path that dominates the model. Cross-border and wholesale platforms carry duties, landed cost and account pricing rather than consumer checkout.
What this sector requires
A variant-aware catalogue
Products as families of variants with an attribute standard your merchandising team can extend. Attribute quality sets the ceiling on search and filtering, and no search engineering recovers data you never captured.
A stated reservation policy
Stock claimed at basket, at checkout or at payment - chosen deliberately per category. Every oversell traces back to a platform where nobody decided which of the three it was.
Refunds as objects
Split across instruments, with their own states and their own settlement timing, so the platform can always answer where a customer's money is rather than inferring it from an order.
An inspected returns path
Authorized, received, inspected, then dispositioned to restock, refurbish or write-off. Money final at inspection rather than at receipt, because those are different facts with different costs.
Honest delivery promises
Computed from measured fulfilment capability rather than declared in marketing. A slower promise honestly kept costs less than a fast one missed, in both support load and repeat purchase.
Sale-event resilience
Sized for concentrated demand on few products, with explicit cache boundaries around stock, queueing rather than errors, and degradation that is designed instead of discovered.
Want to open any of these platforms and look inside before deciding?
See the live demosStock in more than one place is a consistency problem
The moment inventory sits in a warehouse and a store and a marketplace listing, four systems hold an opinion about what is available. Only one of them can be right, and deciding which is an architectural choice rather than an operational one.
The buffer is a commercial decision expressed in code. On a high-margin item with a forgiving customer, promise everything. On a marketplace where an oversell costs you seller standing, hold units back. What fails is applying one buffer everywhere and calling it a setting.
Want your stock model reviewed across the channels you actually sell on?
Talk to an engineerBuilt custom when nothing off the shelf fits
The same team, working from zero. These are the capabilities we build into commerce platforms that no shipped product carries, because they are specific to how you operate.
Omnichannel stock and fulfilment
One stock pool across stores and warehouses, with collection, ship-from-store and in-store returns of online orders, which is where most retail platforms stop short.
Custom software developmentWarehouse and ERP integration
Two-way connections to the systems you already run, so stock, orders and financial postings flow without a reconciliation job somebody does by hand each month.
API developmentSubscription and replenishment
Recurring orders with skip, swap and pause, plus the dunning and churn logic that makes the schedule the product rather than the catalogue.
Backend engineeringCross-border and landed cost
Duties, taxes and restricted-goods rules per destination, shown honestly at checkout so the customer is not surprised by a courier invoice later.
Custom software developmentSearch and merchandising
Relevance tuned on your own behaviour data, with merchandising controls that let a category manager promote without engineering involvement.
Data engineeringB2B quoting and credit
Account pricing, purchase orders, approval chains and credit limits, which the consumer checkout model cannot express and wholesale buyers require.
Custom software developmentNeed something this list does not cover?
Ask about custom workWhat we built, and what it delivered
Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for.
Marketplace
Multi-seller platform with payout reserves
Seller verification and catalogue ingestion, commissions computed from records, and reserves held against an open return window rather than paying out early.
Fashion retail
Apparel platform with an inspected returns loop
Size grids per brand, returns authorized and inspected before refund, and disposition to restock, refurbish or write-off tracked as separate costs.
Cross-border
International storefront with landed cost
Duties and restricted-goods rules per destination shown at checkout, with currency exposure between order and settlement recorded rather than absorbed silently.
We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's.
Want to speak to a reference operating in your category?
Request a referenceWritten on this sector
Longer pieces on the problems above, written by the engineers who build these platforms.
Why you should refund on inspection, not on receipt
InventoryChoosing where to reserve stock, and what it costs
PaymentsSplit-instrument refunds that still reconcile
PeakSurviving a sale event that lands on twenty products
If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build.
Want these as a briefing pack for your board or engineering team?
Request the packWe were refunding on receipt for two years. Nobody could tell me what a return actually cost us, because the system had never been asked to know.
The failure pattern this page is built around
That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented.
Questions commerce buyers actually ask
The ones that come up in the first call, answered as we would answer them there.
Can we really launch in six working days?
Yes, for a shipped platform as it comes, with one fulfilment path. Warehouse and ERP integration is custom work, and it depends on the systems you already run and on their vendors.
Do we own the source code?
Yes, in full, deployed on your infrastructure. No per-order licence, no per-SKU fee, no runtime dependency on us.
How do you prevent overselling?
By choosing a reservation point deliberately and holding a per-channel buffer against the sources of truth that report late. Overselling is a risk you price rather than a bug you eliminate, and the platform should make the choice explicit.
Can we sell on marketplaces as well as our own site?
Yes, with one master stock ledger and buffers per channel. We will steer you away from equal two-way synchronization with no declared authority, because it produces oversells nobody can explain afterwards - but the architecture is yours to choose and we will build to it.
How are returns handled?
As a first-class path: authorized, received, inspected, then dispositioned. The refund becomes final at inspection rather than receipt, which protects you against items that arrive damaged or are not what was sent.
What if a customer paid with a card and a voucher?
The refund is modelled as its own object across instruments, with rules for what can return to each. Expired vouchers and spent loyalty points are policy decisions we make explicit rather than discover during a dispute.
Do you support cash on delivery?
Yes, where your market needs it, including the reconciliation path it creates and the higher return and refusal rates that come with it.
How is fraud handled?
With tunable rules rather than a fixed threshold, because a silent false decline costs more than a chargeback and nobody complains about an order they were never allowed to place.
Can we run stores and online from one stock pool?
Yes, and it is the most common custom requirement in this sector. Collection, ship-from-store and in-store returns of online orders are all scoped explicitly rather than assumed.
Will it hold up during a sale event?
That is the load profile we size against: concentrated demand on few products. Stock is the number we will not serve stale, so cache boundaries are explicit and degradation is designed rather than discovered.
What does support look like after launch?
Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. The first full returns cycle lands weeks after launch, so that window matters here more than in most sectors.
What if we are not ready to build yet?
We will say so. If your fulfilment operation cannot yet meet the promise your platform would make, the platform is not the constraint, and we would rather tell you that than scope work you cannot use.
Question not answered here?
Ask us directlyTell us what you are building.
Bring the catalogue and the return rate. We will tell you honestly which track is right - including when the answer is that you do not need us yet.
A first call takes about thirty minutes and covers four things
Catalogue shape
Variants, attributes, and which categories you intend to add later.
Where stock sits
Warehouses, stores, suppliers, and who else sells the same units.
Return rate
What comes back, why, and what you currently do with it.
Existing systems
The ERP, warehouse and payment stack a platform must fit into.
Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and whether your reverse path is quietly consuming the margin your forward path earns. If the honest answer is that your fulfilment operation needs to come first, we will say that instead of scoping work you are not ready to use.
