The Text I Got Two Days Before a Launch
Two days before a client's product launch, I got a text: "Can we just change one line on the homepage? Should take five minutes." It was a small thing — a headline, a price, a word. On paper, it looked harmless. I said no, and I held that line until the launch was over.
That answer never lands well in the moment. The owner isn't wrong to be annoyed. From where they sit, it really does look like a five-minute fix. What they can't see is what happens on my side of the screen once I touch code that's about to go live in front of real customers. That's what a code freeze is for, and it's worth understanding before you're the one asking a developer to break it.
What a Code Freeze Actually Is
A code freeze is a short, planned period — usually the last few days before a big launch, product release, or deadline — during which the development team stops adding new changes to the software. Not just big changes. All changes, unless something is actively broken for users.
Think of it like locking the doors on a moving truck right before it pulls away. Everything that's supposed to be on board is already loaded and secured. Opening the door again to squeeze in one more box means unstrapping things, shifting the load, and hoping nothing falls out during the drive. A code freeze is that lock.
The freeze isn't a punishment or a sign the developer is being difficult. It's a standard practice used by software teams of every size, from small businesses to companies like Google and Amazon, especially around high-traffic events. The idea is simple: the version of the software that's been tested is the version that goes live. Nothing untested rides along.
Why "Small" Changes Carry Outsized Risk Right Before Launch
Here's the part that surprises most business owners: the size of the change has almost nothing to do with the size of the risk.
Software is built like a chain of connected parts. A price field on one page might feed into a shopping cart calculation, a tax rule, an email receipt, and a reporting dashboard. Change the format of that one field, and three other things can quietly break — not because anyone made a careless mistake, but because nobody had time to check every place that field touches.
Under normal conditions, a change like that goes through review and testing before it reaches customers. Right before a launch, that safety net is exactly what's missing. There's no time left to test thoroughly, no time to catch a problem in a quiet environment, and no time to fix it calmly if something goes wrong. The bug that would have cost ten minutes to catch during a normal week can cost hours of downtime, angry customers, and a scramble to patch a live website during launch day.
This is also why timing matters more than the change itself. The exact same one-line edit that's perfectly safe three weeks before launch becomes risky the day before, simply because there's no longer time left to absorb a mistake.
What Still Gets Fixed During a Freeze
A code freeze isn't a blanket refusal to touch anything, ever. Good developers build in a clear exception: real emergencies still get handled.
An emergency is something that's actively broken for users right now — the checkout page doesn't load, the contact form throws an error, login is failing. Those get fixed immediately, freeze or not, because leaving them broken is a bigger risk than fixing them.
What doesn't qualify: a wording tweak, a color change, a "while we're at it" feature, a new idea that came up in a meeting. Those are valid requests — they're just not launch-day requests. They go on the list for right after launch, when there's room to test them properly. If this sounds familiar, it's the same discipline behind resisting mid-project scope creep — I wrote about that in why "just one more thing" derails a project. A code freeze is that same idea applied to the final stretch, not the whole project.
How to Plan So You're Never Tempted to Break the Freeze
Most freeze-breaking requests don't come from carelessness. They come from a real business need that surfaces late — a typo someone finally noticed, a price that changed, a legal disclaimer that got added at the last minute. The fix isn't to ignore those needs. It's to catch them earlier.
A few habits make this easier:
- Set the freeze date on the calendar, out loud, early. If everyone on the team knows changes stop on a specific day, they naturally front-load requests instead of discovering them the night before.
- Do a full walkthrough of the live site a week out, not two days out. Read every page like a stranger would. Typos and outdated numbers are far easier to catch with a week of runway than a weekend.
- Keep a running "after launch" list. Every idea that comes up late still gets written down — it's just not urgent enough to risk the launch over. Most owners feel better the moment they see it's not being ignored, just sequenced.
- Test changes in a copy of the site before they reach customers, not on the real thing. I've written before about why that separation matters — see staging versus production, explained. A freeze works because there's still a safe place to prepare the next release while the live site stays untouched.
The Launch That Almost Went Sideways
The client with the "quick" homepage change I mentioned earlier launched on schedule, with the old headline still in place. We updated it the next morning, in about the same five minutes they'd asked for — except this time it went through a normal review, on a normal day, with zero pressure and zero risk to the launch. Nobody noticed the one-day delay. Everybody would have noticed if the site had gone down instead.
That's really what a code freeze buys you: not perfection, just the right amount of caution at the moment it matters most. A frozen codebase for three days is a small price for a launch that doesn't need a war room.
If you've got a launch coming up and you're not sure when your freeze should start, or you're staring down a "just one small change" request right now — Let's talk through your situation.