SaaS Cost of Delay Calculator
Put a number on what a slipped release costs, so the argument about the date stops being a matter of opinion.
What this calculates
This adds two costs together. The revenue the work would have earned during the weeks it did not exist, and the team salary spent during those weeks. It measures the revenue side over the twelve months after the original launch date, which is the window a board cares about and the window where a ramp still matters.
At typical inputs for a B2B SaaS company, a six week slip on a release expected to earn $1.2M a year, worked by a team costing $38,000 a week, costs $366,462, which is $61,077 for every week of delay.
Your numbers
The prize
The delay
Results update as you type. Nothing is sent anywhere, the calculation runs in your browser.
Cost of this delay
Live$366,462
$61,077 a week, across 6 weeks of slip
- Cost per day
- $8,725
- Worth paying to save one week
- $61,077
- As a share of the prize
- 31%
Watch
The delay now costs real money every week it continues. Compare the weekly figure against what it would cost to unblock the team. If a contractor, a bought component or a cut in scope costs less than one week of this, that trade is already worth making.
Pressure-test this against your real numbers
Thirty minutes on why the date slipped and what actually changes it.
No email required to see your result. The field above exists only if you want a copy.
How is this calculated?
Two costs, added. The first is revenue you never earn because the feature arrived late, measured week by week across the year after the original launch date with the adoption ramp applied to both the on-time and the delayed case. The second is the team salary spent during the delay itself. Both are real, and most arguments about dates only count the second one.
Formula
ramp(w) = min(1, w ÷ (ramp months × 4.345)) Revenue forgone = Σw=1..52 (ramp(w) − ramp(w − delay)) × (annual revenue ÷ 52) Extra burn = team cost per week × weeks of delay Cost of delay = revenue forgone + extra burn Cost per day divides the total by seven times the weeks of delay.
- The revenue side is measured over the twelve months following the original launch date. Over a longer horizon the forgone revenue converges on exactly one delay period of run rate.
- Adoption is treated as a straight line from launch to full run rate. Real adoption curves are slower at the start, which makes short delays cheaper than this and long ones dearer.
- Team cost is the fully loaded weekly cost of everyone working on the release, including the people who would otherwise be on something else.
- Nothing here counts the competitive cost of arriving second, or the cost of the roadmap items that got pushed behind this one.
When this number misleads
This assumes the revenue was going to arrive at all. If the feature was going to earn less than you projected, the delay cost falls in exact proportion, and the honest answer is that the estimate was the problem rather than the date. Run the number twice, once with your forecast and once with half of it. If the decision changes between the two, you are arguing about a forecast, not about a delay.
Questions founders ask about this
Is the team cost really a cost of the delay?
Yes, because that team could have been on the next thing. The salary is spent either way, but during a delay you are buying weeks of work that produce nothing shippable. That is the part most people leave out of the conversation.
Why does the ramp change the answer?
Because a delay pushes the whole adoption curve back, not just the first month. If it takes three months to reach full run rate, the weeks you lose are early low-revenue weeks and the effect is smaller than the headline. Over a long enough horizon the ramp cancels out entirely, which is why the window here is fixed at twelve months.
What number should I take to the board?
The weekly one. A total is a number people argue with. A weekly rate is a number people act on, because it tells them what one more week of the current plan costs and what they should be willing to spend to avoid it.
Do you store what I enter?
No. The calculation runs in your browser and nothing is transmitted. Your last inputs are saved in your own browser so the page remembers them when you return. If you use the email field, only the result summary and your address are sent.
Book a 30-minute product strategy session
Bring the release that slipped. We will work out what actually caused it and what stops it repeating.
Book a strategy sessionNo pitch deck. No follow-up sequence.