December 9th, a regional delivery company, and a brand-new dispatch tool that had tested beautifully for three weeks. Volume was up 40% for the holiday rush, the client was thrilled to go live before peak, and I was young enough to think "the software works" was the main criterion for deciding whether to deploy software during busy season.
By December 11th, two dispatchers had quietly reopened the old system in a second window. By December 14th, the ops manager, a man who had personally championed the project, asked how hard it would be to "pause this until January." The software worked. That was never the problem.
Here is the direct answer, learned the expensive way: you should almost never deploy software during busy season. Either ship eight or more weeks before peak so the tool is boring by the time volume hits, or freeze and wait. The danger zone in between, where we launched, is where good software goes to get blamed for a calendar decision.
The December Dispatch Launch
Context matters, so here is the scene. A delivery operation doing roughly 900 stops a day in October, ramping toward 1,400 a day by mid-December. The new tool replaced a whiteboard-and-text-message dispatch process that everyone hated and everyone understood. Testing with two friendly dispatchers in November went great. Every workflow ran faster in the new system, on quiet days, with a developer standing nearby.
Peak season changes every one of those variables. Volume doubles, which means edge cases double. The friendly testers get pulled onto the phones, replaced by seasonal staff trained in ninety minutes. And the developer standing nearby is suddenly supporting three times the users with the same one pair of hands. None of this is a software defect. All of it lands on the software.
Should You Deploy Software During Busy Season? Do the Timeline Math
The math is not subtle, but nobody believes it until they have lived it. A new operational tool needs three things before peak, in sequence:
- Training time. Real training, not a lunch-and-learn. Figure one week per distinct user role, longer if seasonal staff arrive late.
- Parallel-run time. At least two weeks where the old and new systems run side by side and someone reconciles them daily. This is where the scary bugs surface.
- Buffer. Two weeks minimum for the things the parallel run reveals, because it will reveal things.
Add it up and you get five to six weeks after the software is "done." If peak starts December 1st, the tool needed to be finished, trained, and reconciled by mid-October. We launched December 9th, which meant all three phases were scheduled to happen during the highest-stakes weeks of the client's year. The timeline was not aggressive. It was fictional.
Week by week, a sane pre-peak schedule looks something like this. Weeks one and two: training, one role at a time, with the loudest skeptics invited first. Weeks three and four: parallel run, old system and new side by side, someone reconciling the numbers every single afternoon. Weeks five and six: fixing what the parallel run exposed, plus the buffer week nobody admits they need until they need it. Week seven: go-live becomes boring, which is the entire goal. Boring launches are the ones that survive contact with December.
What Actually Broke
Three failures, none of them in the bug tracker:
- Muscle memory lost the fight. Under time pressure, dispatchers reverted to the old workflow mid-shift. Not because the new one was worse, but because a person handling 60 calls an hour reaches for the tool they can operate without thinking. Habits need quiet weeks to rewire. December offered none.
- Support bandwidth evaporated. Small issues that would have been two-minute fixes in October (a mislabeled status, a confusing default) became radio silence followed by workarounds. Nobody has time to file a ticket during peak, so problems festered into distrust instead of getting fixed.
- Edge-case volume doubled. The weird 2% of orders, split deliveries and address corrections and the customer who insists the gate code is "just push it," scaled with volume. Two percent of 900 stops is manageable. Two percent of 1,400, compressed into panicked afternoons, is a credibility crisis.
We stabilized it, but the project spent its political capital doing so. The January retro was gentler than it could have been, mostly because everyone was too tired to be eloquent.
The Freeze-Window Rule
Every engagement I run now starts with the client's calendar, and we mark the freeze windows before we mark the milestones. The rule is simple: no go-lives within eight weeks of peak, and no major workflow changes during peak itself.
Why eight weeks
That number is the timeline math from above plus humility. Training, parallel running, buffer, and a margin for the client's seasonal ramp starting earlier than anyone admits. For a December peak, the last safe go-live is early October. For a summer-tourism business, do the same math backward from Memorial Day.
The exception that isn't
Someone always proposes the "soft launch during peak, just for one team." This is the December 9th mistake wearing a trench coat. A partial launch during peak still demands training, support, and attention from people who have none to give. Bug fixes and behind-the-scenes infrastructure work are fine during a freeze. Anything a user can see is not.
What to Do Instead During Peak
A freeze is not a vacation; it is the best build window of the year, because the client is generating mountains of real operational data and war stories. Three things to do with it:
- Run in shadow mode. The new system ingests real data and produces outputs nobody acts on. You find integration bugs with zero user risk, and January-you inherits a tested tool.
- Ship read-only views. A dashboard people can look at but not operate builds familiarity without workflow risk. By January, half the training is done.
- Keep a punch list. Every "I wish the system did X" muttered during the rush goes on the list. Peak season is a requirements factory running at full capacity.
One more peak-season job: selling the freeze to the client's leadership, who will spend November asking why the new thing is not live yet. The answer that works is a story about their own busiest day. Walk the owner through what a broken workflow costs at 2 p.m. on their biggest shipping day of the year, in dollars per hour, and the freeze stops sounding like caution and starts sounding like insurance. You are not delaying value. You are scheduling it for when it can actually land.
That delivery company? We re-launched the dispatch tool in late January, after two shadow weeks and a parallel run. Adoption took nine days. Same software, same team, different calendar. If you want the full anatomy of how an engagement recovers from a launch like ours, the story rhymes with the engagement that failed and with the timeline realities in ninety days in logistics. Integration-heavy launches have their own version of this trap, chronicled in the legacy ERP integration saga. The calendar is a dependency. Treat it like one.