From Quarterly Releases to Daily Earnings
The daily salary
Imagine your salary landing every day instead of at the end of the month. At the same total amount, each euro starts working weeks earlier. You reinvest faster, you smooth out purchases, you seize an opportunity without waiting for the transfer.
Over a lifetime, this simple shift in cadence changes the outcome, through compound interest, not through extra effort.
Shipping software in small increments is exactly that. You’re not producing more value: it’s the same value, starting to compound earlier and more often.
Two reasons, and the second is the most important
1. Uncaptured value never comes back.
Take a feature worth €10k per month. Two teams build it identically, in three months of work.
Team A ships everything in April. Team B slices the work and ships a useful third in February.
Team B captures February and March that Team A let slip by. Those €20k aren’t “delayed”: they don’t exist. You can’t make up a month of value, any more than you can make up a month of undeposited savings.
This is the Cost of Delay: the silent cost of what you haven’t shipped yet.
2. Each increment buys information.
A feature isn’t a savings account with a guaranteed rate. It’s a stock: its return is unknown in advance and only reveals itself once you’ve taken the position, once the feature is in a user’s hands. Before that, its value is just a hypothesis.
And nobody sensible bets their entire savings at once on a single uncertain stock.
You build your position gradually. Take a little, watch how it behaves, reinforce what works, cut what disappoints.
Imagine a search engine planned over three months: search, filters, autocomplete, history. Shipped as one block, that’s a single bet on a stock you don’t know yet.
Ship search alone in week 1, and users might tell you they mostly want filters, and don’t care about autocomplete, the feature you were about to spend three weeks on.
The small increment isn’t just an early payment. It’s a small position that informs you before you reinvest. It turns a conviction into a measurement, and lets you correct course while it’s still cheap.
Shipping early pays. Shipping often keeps you from betting big on the wrong thing.
Why do we get paid once a month?
Not because it’s optimal. Nobody has proven it.
The month is a legacy: processing a payroll was expensive (slips, banks, administration). So payments were batched. It’s a high transaction cost that imposes large batches.
Reinertsen puts it simply: optimal batch size is dictated by transaction cost, not by any virtue of large batches.
The trap: confusing constraint with natural law
“We release every three months.” Stated as a given. It’s a choice, imposed by tooling.
In software, transaction cost has a name: deployment friction, slow tests, manual integration, endless sign-offs.
Continuous integration is precisely what drives it down. Industrialising the “payment” until it’s nearly free: that’s what makes the daily salary possible.
CI isn’t just a quality hygiene practice. It’s the infrastructure that pays you every day.
The two debts
To fund this cadence, you borrow. And there are two very different kinds of debt.
Technical debt lives in the code, the solution space. Good debt is conscious, at a manageable rate, with a repayment plan, like credit to get the asset now. Bad debt is predatory and planless: you end up paying only interest (bugs, workarounds), unable to invest in anything new. Refactoring repays the principal.
Functional debt lives elsewhere: in the gap between the real domain and what the product models, the problem space. Drifting language, missing business rules, anemic models. It’s an unprovisioned liability: commitments made without setting capital aside. The most dangerous kind, because it’s strategic and rarely named.
Where the metaphor ends
Money is fungible and measurable. Value isn’t. Software debt isn’t.
The trap of financial framing is over-quantification: “we have €40k of debt.” A reassuring number, and largely fictional.
Debt on code you’ll never touch never comes due: paying it all off would be waste. And the “compounding” here is socio-technical, not mechanical.
The metaphor isn’t for measuring. It’s for seeing a lever: lower the transaction cost, and the right cadence moves toward continuous.
Further reading: Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas, 2009)