Rework Budget

Two designs for the same feature: three weeks with a rule table inside the existing service that will need replacing, or eleven weeks with a properly separated service. The usual argument is about engineering taste, and it is won by whoever is more tired.

The argument has a number in it. Shipping eight weeks earlier is worth a calculable amount, and that amount is the ceiling on the rework you may knowingly accept. Above the ceiling the shortcut loses money even if it ships; below it, refusing the shortcut is the expensive choice. The budget converts a values dispute into arithmetic a product manager and an architect can both check.

Why it matters

Deliberate debt is a legitimate instrument and is indistinguishable from carelessness without a stated price. The budget supplies the price, and with it three things a plain debt register cannot: a go or no-go test on a specific shortcut, a repayment amount to reserve rather than a vague intention, and a refusal case - "this rework exceeds what the eight weeks are worth" - that survives delivery pressure because it is denominated in the same unit as the deadline.

Implementation patterns

• Quantify the delivery gain first. Volume x affected rate x expected improvement x contribution per unit x weeks earlier. A quick-commerce operator at 45,000 orders a day, cancelling 6% for stock reasons and recovering a third of those at $1.10 contribution, gains roughly $10,000 a week - about $80,000 for eight weeks.
• Price the rework at replacement cost including migration, not at the original build cost, because rework usually means a second implementation plus moving data and callers. Then discount the gain by the probability the feature survives - a shortcut taken for a feature that gets cut was pure cost.
• Reserve the budget as scheduled work with a trigger. "Replace when a second retailer integration is requested" is a trigger; "when we get time" is not.
• Cap the budget as a share of team capacity. Debt service above roughly 20% of output compounds, because the repayment work itself starts being deferred.

Industry example

Dropbox's 2020 account of rebuilding its desktop sync engine is the limiting case, where the budget had been exceeded for years in the other direction. The legacy engine could pass through invalid intermediate states, which made its reachable states unenumerable and therefore unassertable, so 100% of changes paid a correctness review and the failure currency was customers' data. The team judged that accumulated tax large enough to fund roughly four years of rebuild - and the engineer who wrote it up noted the decision would have been a bad one in many environments. The useful reading is that the tax a design charges per change is a measurable quantity, and it is what a rework budget is ultimately denominated in.

Failure scenarios

• The budget quoted and never reserved. The gain is banked, the repayment trigger passes unnoticed, and the shortcut becomes the architecture.
• A shortcut in the expensive-to-change core, with rework priced as local when the shape is already copied into stored data or other teams' code, so the real bill is a migration.
• Gain counted gross, while the rework consumes the next release's capacity and the team is slower across year one.
• The budget used as a licence. Every shortcut is justified against the same headline number, which is then spent several times over.

Trade-offs

A generous budget buys calendar time and pays in future capacity, and that payment falls on whoever is on the team then - an organisational cost, not an accounting one. A tight budget buys predictable capacity and pays in revenue that arrives late or never. Where the shortcut touches a shape other systems will copy, set the budget near zero, because the rework cannot be repaid locally.

When not to use it

Do not budget rework where the failure mode is correctness rather than cost: money movement, auth, data retention, anything a regulator will read. There the comparison is weeks against a liability you cannot price, and a quantified budget gives false comfort. The method also needs a measurable delivery gain; for internal tooling where no contribution figure exists, the honest answer is a qualitative call plus a repayment trigger, not an invented number. And for a shortcut cheaper to repay than to discuss, the analysis costs more than the debt.

Interview question

Q: A product manager wants a feature eight weeks earlier and the fast design will need replacing. Walk me through how you decide, and tell me what you would refuse even if the arithmetic worked.

What a strong answer covers: computing the delivery gain from volume and contribution rather than asserting urgency; pricing rework at replacement plus migration cost; reserving repayment against an observable trigger; and naming the exclusions - persisted data shapes, external contracts, auth and money paths - where the budget is zero.

Quick check

Quiz: Eight weeks earlier is worth about $80,000 and replacing the shortcut will cost about $140,000. What is the call? Do not take it - the rework exceeds the budget, so shipping early loses money.

Flashcard: What converts "ship fast or build right" from taste into arithmetic? — Quantifying the delivery gain and treating it as the ceiling on acceptable rework, with repayment reserved against a trigger.