Resources · Market data
In short
A code freeze is a purchase that rarely gets priced. The data on deployment frequency and cost of delay shows what not shipping costs: deferred revenue, wasted engineering capacity and the burnout that drives attrition. Price one freeze week with four lines you can fill in today, then shrink both the scope and the duration, because each one multiplies the bill.
Most modernization plans arrive with a freeze attached. "We'll need to hold changes to the billing module for six months while we rebuild it." It takes seconds to say and, in our experience, is almost never priced. The rebuild has a budget. The freeze does not.
The engineering lead explains why a moving target can't be rebuilt, the sponsor nods, and the freeze goes into the plan as a condition rather than a cost. But a freeze is a purchase, and you can put a weekly price on it in an afternoon with numbers you already have. Once you do, the question changes from "do we accept a freeze?" to "how short and how narrow can we make it?"
A freeze doesn't pause development. It stops the flow of finished work into production. DORA's 2024 Accelerate State of DevOps report sorts teams into four performance levels. Elite teams deploy on demand, several times a day, with a change failure rate of about 5%. Low performers deploy between once a month and once every six months, with a 40% change failure rate and a week to a month to recover from a failed deployment. About a quarter of teams surveyed sit in that lowest group.
A whole-system freeze puts your team in the low group for its duration, whatever its normal performance. And DORA finds that speed and stability are not a trade-off: teams that ship rarely also ship badly, because changes pile up and go out as one large release. Its guidance on working in small batches explains why. A freeze is the largest batch you can create.
The cost-of-delay literature gives you the other half. Donald Reinertsen, whose The Principles of Product Development Flow is the standard reference, calls cost of delay the one number a product organization must know. In an interview with Lean Magazine he noted that 85 percent of product developers don't know it for their own projects, and that when members of the same team guess, their estimates differ by 50 to 1.
The numbers are rarely small. Joshua Arnold and Özlem Yüce's work at Maersk Line traced one feature whose cost of delay was more than $200,000 per week. It spent 38 weeks waiting in queues, close to $8 million in lost revenue. Not every feature carries that weight, but nobody had estimated it until the queue had done its damage.
In our experience a long freeze costs you in three places, and only the first ever appears in a spreadsheet.
Every initiative that would have shipped during the freeze ships later, and some of its value never arrives because a competitor moves first. This is cost of delay in its plain form: dollars per week, per initiative.
Engineers don't stop working during a freeze. They work on branches that can't be merged, maintain two versions of every fix, or wait. Part of the team's weekly cost produces nothing that reaches production.
In the 2024 Stack Overflow Developer Survey, 63% of professional developers named technical debt as their top frustration at work, and only one in five said they were happy in their job. A long freeze adds a second frustration: not being allowed to ship at all. DORA's 2024 report also found that unstable priorities produce "substantial increases in burnout" that good leaders and good documentation did not offset, and a freeze whose end date keeps moving is unstable priorities in concentrated form. Gallup puts the cost of replacing an employee at one-half to two times their annual salary, before counting the knowledge that leaves with them.
Four lines will do, and each uses a figure you or your CFO can produce today.
Add the first three lines for a price per week. Multiply by the proposed length for the price of the freeze.
Take twelve engineers on a Rails application that runs quoting and billing, at a fully loaded cost of $160,000 each. A rebuild of the billing module is proposed, with a twelve-week freeze on billing at the end. The figures are illustrative.
That comes to about $27,000 a week, or roughly $320,000 for the twelve weeks, and it appears nowhere in the plan. Add the exposure line (an invoicing format change the regulator wants live mid-freeze) and the sponsor has what they need to decide.
Each line of the model scales with how much of the system the freeze covers and how long it lasts. Shrink either and the price falls. Shrink both and it falls fast.
Run the example again, but freeze only the invoice tables for the five working days of a data cutover, with the rebuilt invoicing workflow already proven against the running system. Lost capacity covers the three engineers who touch invoicing, $9,200 of weekly cost at the same 40%: about $3,700. Cost of delay is the pricing change waiting one week, about $5,800; self-serve invoicing is the thing being released, so its delay is zero. Retention risk over one known week is negligible. The total is about $9,500, once, against $320,000.
This is why we don't start from a freeze. Incremental replacement, in the spirit of Fowler's strangler fig, rebuilds one workflow at a time alongside the current system and moves traffic only when the new version is proven. Most workflows never need a freeze. Where one is still needed, typically a data cutover, it covers one set of tables for days.
A publisher's subscription system we worked on had been under a de facto freeze for most of a year while a replacement was debated. When we scoped the cutover of renewals on its own, the freeze actually required was four days on the renewal tables. The rest of the product kept shipping.
"We don't have time to price every freeze. The deadline is next quarter." You can price it in an afternoon, and before it goes into a plan you should agree five things:
Fabrica's CLEAR method is built so that a whole-system freeze isn't needed: Capture records how the running system behaves, Lock approves a System Specification for one workflow, Engineer rebuilds it alongside the current system, Attest tests both against the same specification, and Release moves a customer cohort when the proof supports it, with rollback as a routing change. Where a scope still needs a freeze, usually a data cutover, we agree what it covers and how much interruption the business can accept before work starts, and the pilot measures freeze days as one of its results. Our hypothesis is that this compresses a required freeze to days or weeks for an agreed scope; it is not a promise about an entire migration. How it works shows where a freeze could sit, if at all.
A freeze isn't wrong. Some cutovers need one. What's wrong is accepting it as a free condition of the rebuild when it may be one of the larger costs in the plan. Price one week. Multiply. Then ask how narrow and how short it can be, and what evidence ends it.
Questions to ask before agreeing to a freeze:
Tell us about it on a 30-minute call. We'll suggest a first scope and what a technical review would need to confirm.