A delivery marketplace's infrastructure cost per order is falling while total cost rises. Is that good, and what should the unit metric actually be?

Is it good?

Usually yes, and the metric may be the wrong one.

Falling cost per order with rising total cost is the expected signature of a growing business with improving efficiency — absolute spend should grow with volume; unit cost should not. That is precisely why unit economics is the right frame: it separates growth from waste, which absolute spend cannot.

But cost per order can fall for reasons that are not efficiency gains, and distinguishing them matters:

• Mix shift. If growth comes from a segment that is cheaper to serve, the average falls without anything improving. Segmenting by market, order type and customer tier reveals this.
• Amortisation of fixed costs. Fixed infrastructure spread over more orders lowers the average until the next capacity step, which then jumps. A metric that improves smoothly and then jumps is measuring amortisation rather than efficiency.
• Deferred cost. Storage accumulating, technical debt, retention growing. Cost per order falls today and the accumulated liability appears later.

What the unit metric should be

Several, chosen to isolate different decisions:

• Cost per order — the headline business unit, useful for margin conversations.
• Cost per active user per month — captures the cost of serving users who are not ordering, which cost-per-order hides entirely.
• Cost per search, per catalogue update, per inventory sync — component metrics that let a specific team see the effect of a specific change. A single aggregate cannot attribute improvement.
• Cost per unit of the actual scaling driver. For a delivery marketplace, real-time location updates, dispatch computations and inventory synchronisation scale with different things than orders do, and one of them will eventually dominate.

That last point is the important one: the metric must track what actually drives cost, and if the driver is not orders, cost per order will look fine right up until it does not.

The discipline that makes it useful

• Report unit cost by component and by segment, not only in aggregate.
• Set a trajectory, not a target. "Cost per order declines 10% year on year" is a commitment teams can design against.
• Include the cost of not serving — idle capacity, over-provisioning, reserved commitments — since these are invisible in a per-order figure that divides by successful orders.
• Watch the second derivative. A unit cost improving more slowly each quarter is approaching the limit of the current architecture, which is a design signal well before it is a cost problem.