Why the Safest Way to Ship Software Is to Ship More Often

Every company I have watched go through a bad outage reaches for the same lever afterward: slow down, add a review board, freeze deploys on Fridays, require three sign offs instead of one. It feels responsible. It is usually the wrong move, and the industry's own data backs that up.

Google's DORA research group, whose annual survey has tracked software delivery performance since 2014, found in its 2025 report on AI assisted development, built from nearly 5,000 respondents, that teams using AI coding tools now see real gains in delivery throughput and product performance. But the same report is blunt that "AI adoption does continue to have a negative relationship with software delivery stability," according to Google Cloud's announcement of the report. Ninety percent of respondents said they use AI at work, and 80 percent felt more productive because of it. At the same time, 30 percent said they still have little or no trust in the code it produces. Teams are shipping more, faster, with tools they only half trust, which is exactly the setup that makes a slow-down instinct tempting and exactly the setup where it backfires.

Here is the steelman for slowing down, because it is not a foolish position. Change advisory boards and deploy freezes exist because a bad release is expensive, and reducing the number of releases genuinely does reduce your exposure on any given day. If your team is inexperienced, if your monitoring is thin, or if a single outage would be existential, buying time with process is a rational trade, at least in the short run. I would not tell an early-stage team with no on-call rotation to deploy ten times a day just because a report says elite teams do.

The trade breaks down because slowing releases does not shrink the risk, it just concentrates it. Every feature that does not ship this week piles into next week's release, so the batch gets bigger, the diff gets harder to reason about, and the blast radius of the next deploy grows even as its frequency shrinks. You have not removed risk, you have warehoused it. And even organizations with far more engineering depth than a typical small business are not immune to exactly this failure mode. On August 6, 2026, GitHub Actions went down for roughly nine hours, from 15:05 UTC to 00:14 UTC the next day. According to GitHub's own root cause analysis, as reported in an independent write-up of the incident, the trigger was a routine deployment to an internal Actions service that exposed an existing capacity weakness, and a separate latent bug then let runners retry invalid jobs indefinitely, turning a normal deploy into a cascading failure. At the peak of the incident, 71 percent of workflow runs failed outright and most of the rest were delayed more than five minutes. GitHub ships constantly and still got bitten by one ordinary change, which tells you the lesson is not "deploy less," it is "make each deploy small and reversible enough that this is a five-minute problem instead of a nine-hour one."

Now the math on why this is worth engineering time and not just a platitude. ITIC's 2024 Hourly Cost of Downtime survey, which polled more than 1,000 firms worldwide, found that a single hour of downtime now costs more than $300,000 for over 90 percent of mid-size and large enterprises, and 41 percent report hourly losses between $1 million and $5 million, according to ITIC's own report. ITIC names deployment and configuration errors, not exotic security breaches, as the leading category of human-error causes. A small business will not lose $300,000 an hour, but a bad release does not need enterprise-scale losses to be the worst afternoon of your quarter once you count lost sales, refunds, and the hours your team spends firefighting instead of building. Either way, the cost of the failure mode dwarfs the cost of the fix: feature flags, staged or percentage-based rollouts, and an automated rollback trigger are a few weeks of engineering work, not a re-architecture, and most of the tooling to do it is either open source or already inside the CI platform you are paying for.

The practical version of this for a business owner is not "move fast and break things," it is the opposite: decouple deploying code from releasing a feature, so a bad change reaches 1 percent of traffic before it reaches 100 percent, and make rollback a single command instead of a meeting. Write the runbook before you need it, not during the outage. That is the actual difference between GitHub's nine-hour incident and what a five-minute one looks like, and it is the same pipeline work MojoSoftware builds for clients launching new releases, because the goal was never zero risk. It was making the next mistake small. If your release process still depends on getting everything right the first time, let's talk about fixing that before it costs you a Saturday.