I inherited a 50-minute deploy, and it was the best news in the audit

When Revin stepped into this client, the production deploy took fifty minutes and nobody could say why. It took me a while to see the number was not the problem, it was the symptom. Here is what was underneath, and why a slow deploy costs far more than it looks.

Por Victhor Araújo

Victhor Araújo

The first time I watched that client's deploy run all the way through, I clocked it without meaning to. Fifty minutes. We had just taken over a logistics product an agency had run for almost two years, with a team of four developers inherited along with it, and I was there only to watch the ritual before touching anything. Nobody in the room found fifty minutes strange. That was the part that bothered me, not the clock.

The deploy went out twice a week, Tuesdays and Thursdays, always after six in the evening, always with one specific person on call watching the log scroll. If it broke at minute forty-two, the whole thing started over. One Friday a silly one-line hotfix took almost two hours to reach production because two deploys queued up and the second one died halfway. One line. Two hours. And the team still treated that like weather: you do not argue with it, you just bring an umbrella.

If you are a founder and your team has already normalized some slow ceremony as "it has always been this way", this piece is about your product, even if your number is a different one.

The production deploy lived in a script on one developer's laptop. When he took time off, the whole product took time off with him.

What fifty minutes hide

The deploy time is rarely the real cost. The cost is what that time stops the team from doing. With a fifty-minute deploy that could still fail near the end, the crew had learned to deploy as little as possible. They piled two weeks of change into a single release, because paying the toll was a drag. And the more that ships at once, the higher the odds something breaks, and the harder it is to find out what.

The expensive part has nothing to do with the fifty minutes on the timer:

• Bottled-up releases: a finished feature waiting days for a safe deploy window.
• Bugs that cost to find: when twenty commits ship together, figuring out which one broke turns into an investigation.
• Fear of touching: nobody edits old code near the window, so the debt just keeps growing.
• The one-person bottleneck: the person on call had not taken a real vacation in over a year.

Add it up and the client did not have a DevOps problem. They had a business-velocity problem dressed as a technical one. I have written before about why measuring this with the wrong metrics only makes the diagnosis worse, in DORA is the wrong thermometer for small teams.

Whose fault is it when the deploy rots

The developer running the deploy was excellent, write that down. The problem did not start with him. It started with the model of whoever built it before: an agency paid per feature shipped, scope locked by contract. In a relationship like that, automating the deploy is work that never shows up on the invoice. Nobody spends three days standing up a decent pipeline when those three days could become one more screen to show at the status meeting.

Calling that carelessness would be unfair. It is the contract working exactly as designed: you pay for what you can see, and a good deploy is invisible. The vendor who walks away when the scope closes has no reason to care about the deploy a year from now either, because they will not be here to run it. That is how fifty minutes became normal. Each sprint stacked a little more manual on top of manual, and nobody whose name was on the contract had any incentive to stop and fix it.

When two deploys queue up and the second one fails at minute forty, the error stopped being technical. It became a process.

What we did in three and a half sprints

Nothing we did was heroic. First we stopped treating the deploy as an event and started treating it as routine. We containerized the app, a Rails monolith with no Docker, shipped over rsync, moved the pipeline into GitHub Actions, and went after the two obvious bottlenecks in the build: the test suite ran in series and the image rebuilt everything from scratch every time. Layer caching and parallel tests took out most of it.

The deploy went from fifty minutes to nine, and from twice a week to as many times a day as the team wanted. That nine is too pretty to be an honest average, I admit it: I grabbed the best case, with a warm cache. A cold deploy still runs around thirteen. But thirteen minutes, several times a day, is another planet next to fifty minutes, twice a week, scared.

The side effect mattered most. That one-person bottleneck took three weeks off at the end of that quarter and the deploy kept going out without her. Nobody had to call begging for help. For the first time in a long while, the product did not depend on one specific person being awake.

Why a squad that stays sees this differently

A team that will maintain what it writes treats the deploy as its own business, not as someone else's boring chore. If I know that a year from now I will still be here running this same deploy every week, I am not going to leave it at fifty manual minutes, because it hurts me before it hurts the client. That difference in incentive is what changes the code. And it is exactly what a senior embedded squad puts on the table: people who take on the product as if they will stay on it, because they will.

This is the kind of thing we usually catch in the first read of the codebase, during the Diagnostic Sprint, normally within the first two weeks, before it becomes the Friday-at-seven crisis. And if you want to see the pattern undone in a real situation, the cases tell it better than I can.

Back to the fifty minutes

When I tell this story, the part people keep is the number, fifty dropping to nine. For me the part that matters is a different one. Nobody at that company decided to live with a fifty-minute deploy. It just drifted there, with no decision, sprint after sprint, under a vendor with no reason to look. Almost every bottleneck we find is like this: it is not a bad choice someone made, it is a choice nobody made, piling up while the team was busy shipping screens.

If you suspect there is an "it has always been this way" running in the background of your product, it is far cheaper to find out now than on a Friday at seven in the evening. Whenever you like, book a call.