A quick-commerce business wants to improve its ten-minute promise. The engineering team optimises the checkout API. Why is that likely the wrong target?

The value stream

The customer's promise decomposes into: browse and select, checkout, order routing, picking at the store, packing, courier assignment, courier travel to store, collection, and delivery.

Software controls perhaps a third of the elapsed time. If picking takes four minutes and the ride takes five, then shaving 200ms from checkout changes nothing the customer perceives.

Why the wrong target gets chosen

Teams optimise what they own and can measure. The checkout API's latency is visible in a dashboard the engineering team looks at daily; the picking time is in an operations report they never see. The optimisation is chosen by the org chart rather than by the value stream.

What value stream mapping produces

• The elapsed time of each step and, crucially, the wait time between steps. In most value streams the waiting dominates the working, and the largest improvements come from removing handoffs rather than from speeding up work.
• The variance, not just the mean. A step that usually takes two minutes and occasionally takes twelve is the one setting the promise, because the promise must accommodate the tail.
• The constraint. Improving anything other than the constraint changes nothing, which is a counter-intuitive result that is reliably true and reliably ignored.

Where the software leverage actually is

Not in making the software faster, but in making the physical process better:

• Batching and routing intelligence that reduces courier idle time between orders.
• Stock placement forecasting, since an item in the wrong store cannot be delivered in ten minutes at any software speed.
• Pick-path optimisation in the store, which addresses the largest software-influenceable component.
• An ETA model rather than a constant, so the promise reflects the current state and degrades to a conservative value when inputs are stale.

The architectural conclusion: the leverage is in the systems that shape the physical process, not in the systems that serve the request.