Do the Maths Before You Blame the Pipeline: What a Botched Release Actually Costs a Small Firm
Photo: server room outage engineer laptop stressed night office, via thumbs.dreamstime.com
There's a particular flavour of dread that hits when the Slack channel lights up three minutes after a release. Someone posts a screenshot. Someone else says 'works on my machine'. And somewhere in the background, a customer is doing sums about how long they've been unable to check out.
We tend to talk about bad deploys as a technical problem. They're not. They're a money problem, and if you're running a small UK business, the numbers are more uncomfortable than most of us would like.
Where the Money Actually Goes
Ask a developer what a failed release costs and they'll say 'a few hours fixing it'. Ask an IT manager and you'll get a very different answer. We spoke to half a dozen people running tech at UK firms between ten and a hundred staff, and the same cost buckets kept coming up.
Lost revenue, per minute. One ecommerce operator we spoke to pegged it simply: average order value times conversion rate times sessions per minute. For a modest shop doing £2m a year, that's roughly £4 a minute during peak hours. Not apocalyptic — until a bad deploy takes the checkout down for four hours on a Saturday.
SLA credits and penalties. If you're B2B with a 99.9% uptime commitment, you don't get to shrug. One managed services firm described a single afternoon outage that wiped out a quarter's worth of margin on one contract. The maths is brutal: 99.9% gives you about 43 minutes of downtime a month. One bad deploy can burn the whole budget.
The human cost. This is the one nobody puts in the spreadsheet. Two developers pulled off feature work for a day. A support queue backing up. Someone missing the school run because the rollback went sideways at four o'clock. One IT manager told us, bluntly, that the real cost of their worst deploy was losing a good engineer six months later.
A Calculator You Can Actually Use
Here's the napkin version. Fill in your own numbers:
- Revenue per hour = (annual revenue ÷ 1,800 trading hours) × peak-hour multiplier
- Incident cost = revenue per hour × hours down + SLA credits + (hourly dev cost × devs involved × hours spent)
- Annual deploy risk = incidents per year × cost per incident
A fictional-but-realistic example: 30-person SaaS firm, £3m revenue, two bad deploys a year averaging three hours each, two devs on the fix, one contract with credits. You land somewhere north of £15,000 a year — before you count the opportunity cost of what those developers would otherwise have shipped.
Now compare that to the price of a proper CI/CD setup: automated tests, staging that actually mirrors production, feature flags, a rollback button people trust. Even with a contractor's day rate, you break even inside a year for most SMEs.
The Counter-Argument, Honestly Stated
To be fair to the sceptics: most deploys don't fail catastrophically, and over-engineering your pipeline for a five-person agency is its own form of waste. If you ship twice a month to a handful of internal users, a checklist and a brave face might genuinely be fine.
The calculation tips when three things are true: customers depend on you in real time, you have contractual uptime promises, or your deploys require someone to be 'on standby'. If any of those apply, the maths above is your business case, written in your own numbers.
The next time someone proposes spending a sprint on deployment infrastructure, don't argue about best practices. Argue about pounds. That's a conversation the board can have.