A quick-commerce grocery operator running dark stores needs substitution handling for out-of-stock items. Option A is a rule table inside the existing order service: three weeks and it will need rework. Option B is a separate availability-and-substitution service with its own store: eleven weeks. The business does 45000 orders a day, cancels about 6% of them for stock reasons, expects the feature to recover roughly a third of those, and earns about 1.10 dollars of contribution per order. Roughly what is the cost of delay, and what rework budget does it justify?

The assumptions, stated

Four numbers carry the whole estimate: 45000 orders a day, a 6% stock-related cancellation rate, a one-third recovery rate for the feature, and 1.10 dollars of contribution per recovered order. Only the first two are measured. The third is a product guess and the fourth comes from finance.

The arithmetic

• Cancellations: 45000 × 0.06 = 2700 lost orders a day.
• Recovered at one third: 2700 ÷ 3 = 900 orders a day.
• Value: 900 × 1.10 = roughly 1000 dollars a day, so about 30000 dollars a month.
• The two options differ by eight weeks, so shipping A first is worth 56 × 1000 = roughly 55000 dollars.

Now price the rework. Say the rule table has to be pulled out into its own service within a year: 6 engineer-weeks at a fully loaded 5000 dollars a week, a 2026 order-of-magnitude rate, is about 30000 dollars.

Ship A. The delay costs about 55000 dollars and the rework costs about 30000, so the shortcut wins by roughly two to one — and that comparison is only valid because the rework figure is bounded.

Which assumption dominates the error

The recovery rate. Nobody has measured it, and it is the multiplier on everything. At a third, delay costs 55000 dollars. If substitutions only recover 10% of cancelled orders, delay costs about 17000 and the two options are within noise of each other, at which point the eleven-week build is defensible. The cheapest thing the team can do this week is measure it: offer manual substitutions by phone on 2% of affected orders for a fortnight and count acceptance.

What the number rules in and out

It rules out an eleven-week build justified by maintainability alone, because nobody has shown the recovery rate that would pay for it. Choose the shortcut only if the rework can be bounded, since an unbounded rework figure makes the whole comparison meaningless: a substitution rule table that fails quietly and mis-substitutes items damages the customer relationship in a way no engineer-week figure captures. The rework estimate is the load-bearing part of the decision, and it holds only while the shortcut stays inside one module: one rule table read by the order service, no new columns in the order row, no substitution ids exposed to retailers.

When this is the wrong answer

The bill arrives when substitution rules need to vary per retailer. At one retailer a rule table is a table. At forty retailers with contractual rules about which brands may be substituted for which, it becomes a rules engine with an approval workflow, and the 6-week rework estimate turns into 25 engineer-weeks because retailer contracts now depend on its behaviour. If the retailer count is going from 1 to 40 inside the year, price the rework at that number instead, and the delay argument collapses.

Common weak answers

• "Ship fast, we can always refactor." Not an answer without a rework figure. The whole case rests on 6 engineer-weeks being credible, which is a claim about containment.
• "Build it properly, technical debt always costs more." At 1000 dollars a day of forgone contribution, eight weeks of properness has a price tag, and someone has to say it out loud.