Retail & eCommerce
Retail systems are sized for a handful of days a year. The rest of the time capacity is a rounding error, and on those days every weakness in the inventory model becomes a customer-service problem.
Inventory accuracy is the real constraint
Most visible commerce failures trace back to stock. Overselling, phantom availability, items reserved by abandoned carts that nobody released — all of it is one problem: the number in the database and the number on the shelf have diverged, and the system was designed as though they could not.
Reservations with expiry, an explicit and auditable reconciliation with physical counts, and a considered answer to what happens when two customers want the last unit at the same moment. That last case is a business decision about which channel wins, not something to leave to whichever transaction commits first.
Where we work
Commerce platform engineering
Extending or replacing storefront and checkout systems, including the integrations that make a replatform expensive.
Inventory and order management
Availability across channels and locations, with reservations that expire and counts that reconcile.
Pricing and promotions
Rules engines where an unexpected discount stack is caught before it reaches customers rather than after.
Fulfilment integration
Warehouse, courier and store-fulfilment flows including returns, which are usually scoped last and cost the most.
Search and merchandising
Relevance tuned against your catalogue and actual queries, not against a benchmark from someone else's data.
Customer data and personalisation
Segmentation and recommendations built on a consent model that survives a privacy review.
Constraints that shape the work
Stock accuracy sets the ceiling
Oversell rate, not page speed, is what turns customers away. Every architecture decision here is downstream of how reliably you know what you have.
Peak is a different system
The behaviour that matters happens in four hours a year. Capacity, caching and queueing are designed for that window, then proved by load testing against it.
Promotions collide
Stacking rules, exclusions and edge cases are business logic, not configuration. They need tests, because they will be changed under time pressure by someone who is not an engineer.
Fulfilment is asynchronous
Warehouse and courier systems answer late and sometimes not at all. Order state has to be recoverable when a downstream system loses a message.
Peak is a design constraint, not a capacity setting
Autoscaling handles a busy day. It does not handle a system whose slowest component is a synchronous call to a third party that has also had a busy day. Peak failures are usually structural — a dependency that cannot be scaled, a lock held too long, a queue with no back pressure — and no instance count fixes them.
The productive exercise is deciding in advance what degrades. If the recommendation service is slow, the page should render without it. If tax calculation times out, checkout needs a defined answer. Choosing those behaviours in October is much cheaper than discovering them in November.
- Load tested against realistic catalogue and cart shapes, not synthetic uniformity
- Non-essential features degrade independently rather than blocking a page
- Third-party dependencies wrapped in timeouts and circuit breakers
- Idempotent order handling, so a retried payment cannot double-charge
- A rehearsed freeze and rollback plan for the peak window
When not to hire us
If you are on a hosted platform and your problems are merchandising and margin, replatforming is an expensive way to avoid a commercial decision. We will say so in the first call.
We are also the wrong choice for a rebuild scheduled to launch inside your peak trading window. Nobody should be finding out how a new checkout behaves under real load on the busiest day of the year.
Common questions
Extend, unless the platform is genuinely the constraint. Replatforms are dominated by the integrations nobody documented — tax, fulfilment, loyalty, the report finance depends on — rather than by the storefront. We would audit what actually touches your current system before recommending a migration.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.