All the Gear, Never a Deploy: Your CI/CD Pipeline Is Just Expensive Procrastination

Let me describe a team I've heard about from roughly a dozen different people in roughly a dozen different industries. They have a CI/CD pipeline. They are very proud of this pipeline. They have a Slack channel dedicated to pipeline notifications. They have a dashboard. The dashboard has graphs. The graphs are, by all accounts, quite attractive.

They ship code approximately once every three weeks.

This is not a rare situation. This is, in fact, an epidemic — and it is being spread by a particularly British strain of technical perfectionism that mistakes the scaffolding for the building.

The Pipeline as Status Symbol

At some point in the last decade, having a sophisticated CI/CD setup became a proxy for engineering maturity. And fair enough — at scale, you genuinely need robust automation to ship safely and frequently. The problem is that 'at scale' got quietly decoupled from the conversation, and now teams of four people maintaining a modest SaaS product are running deployment infrastructure that would make a mid-sized fintech blush.

Ask why, and you'll get answers that sound reasonable in isolation. 'We want to catch regressions early.' Fine. 'We need a proper audit trail.' Sure. 'Security insisted on a scan at every stage.' Understandable. 'We added a manual approval gate after that incident in March.' Ah. Now we're getting somewhere.

Because what actually happens, in practice, is that each of these sensible-sounding requirements accumulates. Nobody removes a stage once it's in. Nobody asks whether the forty-minute security scan is catching anything that a fifteen-minute one wouldn't catch. Nobody notices that the 'manual approval gate' has become a bottleneck that means every deployment requires a senior developer to be at their desk, not in a meeting, and in the right mood to click a button.

The pipeline grows. The shipping slows. The graphs remain attractive.

Continuous Integration, Discontinuous Delivery

Here's a test worth running. Ask your team: 'When did we last deploy to production?' Then ask: 'When did we last make a meaningful change to the deployment pipeline itself?'

In teams suffering from what I'm calling Pipeline Theatre, the second answer is usually more recent than the first. The process is being actively maintained and improved. The product is not. This is, to use a technical term, backwards.

The original promise of CI/CD was beautiful in its simplicity: make small changes, integrate them frequently, deploy them quickly, catch problems early when they're cheap to fix. It was a philosophy built around moving faster with confidence. The confidence was meant to enable the speed, not replace it.

Somewhere along the way, the confidence became the product. Teams optimised for the feeling of safety rather than the reality of shipping. And the feeling of safety, it turns out, is extremely expensive to maintain and produces no revenue whatsoever.

The Beermat Test for Your Pipeline

Here's a genuinely useful exercise. Draw a beermat. On one side, write down everything your pipeline does. On the other side, write down the last three production incidents you actually had and what caused them.

Now compare the two lists.

If your pipeline caught any of those incidents before they hit production, brilliant — those stages are earning their keep. If your production incidents were caused by things your pipeline couldn't possibly have caught (a third-party API change, a customer doing something unexpected, someone updating a config file manually because the pipeline was too slow), then you have a very expensive system protecting you from problems you don't actually have.

This is not an argument for removing all your guardrails and deploying directly to production from a laptop in a coffee shop. It's an argument for being honest about what your guardrails are actually guarding against, and whether the cost — in time, in complexity, in the sheer cognitive overhead of maintaining the thing — is proportionate to the risk it mitigates.

What Shipping Daily Actually Looks Like

'We ship daily' has become one of those phrases that engineering teams say in the same way that people say 'we're really close with our family' — technically possible, but worth examining before you repeat it at a dinner party.

Actual daily shipping is genuinely achievable for most small to medium software teams. But it requires a specific kind of discipline that is almost the opposite of what most pipeline-heavy teams practise. It requires simplicity. Small changesets. Fast feedback. A deployment process that takes minutes, not hours. A culture where 'good enough to ship' is a valid engineering standard rather than a sign of laziness.

Teams that ship daily don't tend to have seventeen-stage pipelines. They have three or four stages that do the things that actually matter — run the tests, check the obvious things, push the code — and they've made a deliberate choice to accept the marginal additional risk in exchange for the enormous practical benefit of having their software in front of real users, generating real feedback, every single day.

The marginal risk, incidentally, is almost always smaller than it feels. Most bugs that make it through a streamlined pipeline are caught within hours by users and fixed within the same day. Most bugs that make it through a seventeen-stage pipeline are caught within hours by users and fixed within the same day. The pipeline did not save you. It just took longer.

A Modest Proposal

Spend a day — just one day — treating your deployment pipeline the way you'd treat any other piece of software in your product. Audit it. Question every stage. Ask 'what does this catch, and how often?' Delete anything that can't give a satisfactory answer.

You will almost certainly end up with something shorter, faster, and more honest. You will probably ship more frequently. You will definitely spend less time maintaining the pipeline itself and more time maintaining the product.

The beermat version of a good deployment process fits on a beermat: run the tests, check it builds, push to staging, smoke test, push to production. Everything else is either solving a real problem you have documented evidence of, or it's theatre.

The show has been running long enough. Time to ship something.