Unit Cost Ceiling
also called Cost per Transaction Limit, Infrastructure Cost Budget per Order
The infrastructure cost per transaction that the business model can bear, derived from contribution margin and fixed before design, which decides how much work a request is allowed to do.
A marketplace takes 12% of a 400-rupee order, so 48 rupees, and keeps about 15 after delivery partners and payment fees. An infrastructure design costing 3 rupees per order consumes 20% of that contribution, before support, salaries, marketing or discounts. The same 3 rupees against a subscription product with 1,600 rupees a month of room per customer is a rounding error.
The architecture is identical in both cases; only the ceiling differs. A unit cost ceiling makes that number explicit before the design exists: the cost per transaction the business can carry, expressed as a share of contribution. A defensible figure for a thin-margin marketplace is on the order of 2 to 5% of contribution, which here is roughly 0.3 to 0.75 rupees an order.
Why it matters
Infrastructure cost in a transactional business scales with success, which is the opposite of how software economics are usually described in a design review. A per-order design that is invisible at 10,000 orders a day is 6 million rupees a day at 2 million orders, and by then it is load-bearing: services depend on it, caches assume it, and removing it is a quarter of engineering at the exact moment margin is under scrutiny. The bill arrives at the scale that was the goal.
The ceiling also settles arguments that are otherwise unresolvable. "Should we run inference per order?" has no technical answer. "Do we have 0.5 rupees an order for inference?" has one, and it can be decided by someone with the authority to spend it.
Implementation patterns
- Derive it, do not guess it. Take revenue per transaction, subtract variable costs that are not infrastructure, and allocate a stated share of what is left. Write the arithmetic in the design document.
- Express the design's cost in the same unit. Cost per order, per active user per month, per API call, per GB ingested — whatever the business charges for. A cloud bill by service does not constrain a designer; a cost per order does.
- Prefer precomputation to per-request work. A recommendation computed once an hour and read from a cheap store costs a fraction of one computed per page view, and users cannot tell the difference.
- Decide read paths by the ceiling. A materialised view is cents where a five-service fan-out with a query each is not.
- Put the number on a dashboard the platform team owns, next to latency and error rate, reported monthly. A number nobody reports constrains nobody.
- Attach the ceiling to the load test. A performance test that reports cost per transaction at 10x traffic turns the future bill into a present fact.
- Record the exception. When a design exceeds the ceiling deliberately, write down the volume at which it must be revisited, so the revisit is triggered rather than remembered.
Industry example
The discipline is visible wherever margin is thin and volume is large. Dropbox's Magic Pocket programme, completed in 2016, moved file storage off rented object storage and onto its own hardware, and the published reasoning is unit economics at exabyte scale: at sufficient volume, the per-gigabyte cost difference exceeded the cost of building and running a storage system. The same logic runs in the other direction for smaller companies, where the build cost dominates and renting is obviously right.
The reverse case is equally instructive: teams that added per-request machine-learning inference without a ceiling, then discovered at volume that the inference cost more than the transaction earned, and had to retrofit caching and batching under commercial pressure.
Failure scenarios
- A step change in the bill after a launch, traced to one design decision that multiplied rather than added.
- Success becoming the crisis. Growth triples volume and the margin does not survive it, so the response is an emergency cost programme instead of a product roadmap.
- Optimisation that arrives too late to be cheap, because the expensive path is now depended upon by four services.
- Cost pushed onto the platform team, who cannot fix it because they do not choose how much work happens per order.
- A ceiling set and never reported, which is the most common failure: everyone agrees with the number and nobody sees the actual.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| A ceiling set before design | Cost is a constraint rather than a discovery | Some designs are refused for a bill that may never arrive |
| No ceiling, optimise later | Maximum speed early | Optimisation lands when the design is load-bearing |
| Precompute and cache | Cost per request falls sharply | Staleness, and a cache to invalidate |
| Pay the higher cost deliberately | The better product experience | A recorded volume trigger to enforce, or the same crisis later |
When not to use it
Before product-market fit, this is a distraction. A startup with 500 orders a day that optimises cost per order is optimising a number that will be irrelevant if the product fails, and the engineering time is better spent finding out whether it does. The ceiling starts to bind when a plausible plan multiplies today's volume by 100 and the arithmetic stops working; that is the moment to do it, and not before. It also does not apply to costs that do not scale with transactions: a fixed monthly platform cost is a budget question, not a unit-economics one. The rule is to choose the expensive design deliberately, with the multiplication done, and to write down the volume that forces a revisit.
Interview question
Q: A platform proposal adds 3 rupees of infrastructure cost per order in a marketplace that keeps 15 rupees of contribution. Walk me through how you decide, and what you would put in place either way.
What a strong answer covers: doing the arithmetic as a share of contribution rather than of revenue; noting that the cost scales with volume so the decision is about a future bill, with the multiplication shown; the alternatives that change the number by an order of magnitude — precomputation, materialised views, batching; who is entitled to approve an exception and what the trigger for revisiting is; and the reporting mechanism, because an unreported ceiling constrains nobody.
Quick check
Quiz: Why is "infrastructure is cheap compared with engineers" a weak argument in a marketplace? Because the comparison that matters is against contribution per transaction, which scales with volume, while payroll does not.
Flashcard: How do you derive a unit cost ceiling? — Revenue per transaction minus non-infrastructure variable costs gives contribution; allocate a stated share of it, on the order of 2 to 5% for a thin-margin business, and express every design's cost in the same unit.