Why Your Dev Team Is Slow to Ship

You asked for a three-word copy change on the pricing page. Your developer told you it was done that afternoon, and then it went live nine days later.

You didn’t say anything, because the last time you pushed on timing you got an answer about staging and the release branch and you weren’t sure which follow-up question wouldn’t make you look foolish. So you filed it away with the other times a small thing took a long time, and now you have a quiet suspicion you can’t prove: either your team isn’t very fast, or something in how they work is broken, and you can’t tell which one you’re paying for.

It’s almost always the second one. In twenty years of building software I have met very few slow developers. I have met a lot of teams where the code was finished in an hour and then sat in a queue for a week waiting on a manual test pass, a release window, and one person who happened to be on vacation. The typing was never the bottleneck.

The number that matters here is lead time: how long it takes for a change to go from “a developer finished it” to “a customer can use it.” On one enterprise platform I worked on, that number was two months when we started and one day when we finished, and we got there without hiring anyone or asking anyone to work harder. We found where the changes were sitting idle and removed the reasons they were sitting there.

Why this matters now

If your first version came out of Lovable, Replit, Base44, Bolt.new, or Cursor, you got used to a very particular feeling: you described a change, and a minute later it was live. That was real. It was also happening without tests, without a staging environment, without any review, and without a way to undo a bad change, which is fine when nobody is paying you and catastrophic when they are.

So the first thing that happens after you hire a real developer or an agency is that everything gets slower, and nobody explains why. Some of that slowdown is the price of not breaking your product in front of paying customers. Some of it is pure waste that your team has stopped noticing because it’s just how things have always worked there. Founders almost never have the vocabulary to tell those two apart, so they either accept every delay or push on all of them, and both are expensive.

You do not need to learn to code to sort this out. You need to understand what happens between “done” and “live,” and you need four questions to ask your team, which I’ll give you at the end.

What actually happens between “done” and “live”

The path a change takes, in plain terms:

A developer writes the change on their own machine. Another developer reads it and approves it, which is called code review (if you only have one developer, this step usually gets skipped, and that’s a separate conversation). The change gets merged into the shared copy of the code. Something has to verify the product still works, either automated tests running in a few minutes or a person clicking through the app for an afternoon. Then the change gets copied onto the servers your customers use, which is the deploy. Then somebody watches to see whether anything broke.

Every one of those steps can be automated end to end. On the SaaS product I built and shipped solo, the pipeline ran on every change: tests, build, deploy, and a set of checks against the live system to confirm the deploy was actually healthy. Start to finish, under five minutes, with no human in the loop. That is not an exotic setup. Tools like GitHub Actions and Terraform do exactly this, and at startup scale they cost close to nothing.

A slow team looks nothing like that. The change waits two days for review because the only senior developer is busy. It waits four more days because QA tests in a batch on Thursdays. It waits until the next release window because deploys are scary and the team only does them on Tuesday nights. The deploy itself takes an hour because someone is following a checklist by hand. Same change, same developer, same amount of actual work. Nine days.

One hour of that was work, and the other eight and a half days were waiting. When founders ask me why their team is slow, they are almost always asking about the hour, and the answer is in the waiting.

The four things that set your speed

Batch size

This is the biggest lever and the least intuitive one. Teams that ship small changes constantly move faster than teams that bundle everything into a monthly release, and they also break things less often.

The reason is uncomfortable if you’ve never seen it: when twenty changes go out together and the product breaks, nobody knows which change did it. Finding out takes hours. When one change goes out alone and the product breaks, you know exactly what to undo, and you’re back to healthy in minutes. Big releases feel safer because they involve more ceremony, but the ceremony is there to manage a risk the batch itself created.

If your team is doing a “release” as an event, with a calendar invite and someone staying late, you’re paying for that feeling.

Automated tests

Tests are what let a team move fast without being reckless. They’re code that checks the rest of the code, and they run in minutes instead of an afternoon of somebody clicking.

Without them, every change requires a human to re-verify the product by hand, so either the team slows down to test properly or they stop testing and start shipping bugs. Most teams under deadline pressure quietly choose the second one. Then you get a support email, they fix it in a hurry, that fix breaks something else, and three months later your developers are spending most of their week on problems they created rather than on the roadmap you’re paying for.

If your product was AI-generated, assume it has close to zero test coverage. The models are very good at producing features and generally do not produce the tests unless someone specifically asks. Claude Code and Cursor will write them if you tell them to, and that is a reasonable first thing to ask your developer to spend a week on.

The ability to undo

The single best question to ask your team is: if we ship something bad right now, how long until customers are back on the working version?

If the answer is under ten minutes, your team will ship confidently, because a mistake is a small annoyance. If the answer is “we’d have to figure that out,” every deploy feels permanent, and people slow down in proportion to how scared they are. I have watched teams add weeks of review process to a codebase when what they actually needed was a rollback that worked.

Related to this: feature flags let a change go out to production turned off, then get switched on for a few customers, then everyone. That separates putting code on the servers from letting customers see it, so the deploy stops being the scary part. You turn the feature on when you’re ready, and you turn it off in seconds if it misbehaves.

Environments that match production

Your team needs somewhere that looks like the real product to test against. When staging is a stale, half-broken copy that nobody trusts, testing there proves nothing and everyone knows it, so the real test becomes production and everyone gets nervous.

The version of this I like is ephemeral environments: every proposed change automatically gets its own temporary copy of the whole product, built from the same Terraform code that builds the real one, and it disappears when the change is merged. You can click through the actual feature before it merges. That’s worth more to a founder than any status update, and it’s a normal thing to ask for.

Anti-patterns to avoid

Hiring more developers to go faster. If the bottleneck is a week of waiting, adding a third developer adds a third stream of work into the same queue. Sometimes it gets slower, because now there’s more coordination and the same one person is still doing every deploy. Fix the flow first. Hiring someone to find out whether hiring was the problem is the most expensive experiment you can run.

Adding process after an outage. Something breaks, everyone is shaken, and the response is a new approval step. Six months later there are five approval steps, everything takes two weeks, and the outages still happen. I have never seen an approval step catch a bug that automated tests would have missed. What it reliably does is move the change to the back of somebody’s queue.

Accepting “we need a code freeze.” Freezes before a big launch or an investor demo feel prudent. What they actually do is pile up a large batch of untested changes that all get released together the moment the freeze lifts, which is the riskiest possible moment. If your team can’t ship safely during an important week, they can’t ship safely, and the freeze is hiding that.

One person who can deploy. If deploys live in one engineer’s head or on one engineer’s laptop, your shipping speed depends on that person being available, and you are in real trouble the week they quit or go on vacation. This is the same problem as infrastructure that only exists because someone clicked the right buttons once. The fix is the same too: put it in code, in the repository, where anyone can run it.

Compliance as an excuse. I’ve heard “we have to move slowly because of the audit” more times than I can count, and I’ve never found it to be true. I reduced deployment ceremony on a platform under SOX compliance and came out with better audit evidence than we had before, because an automated pipeline logs every step and a human checklist doesn’t. Regulated means documented, and a pipeline documents every step whether or not anyone remembers to.

How to start, gently

You don’t need to reorganize anything this week. Start by finding out where you actually stand.

Ask these four questions, and listen for hesitation more than for the numbers:

1. When a developer finishes a change, how long until a customer has it? Ask for a real recent example, not an average.
2. What percentage of a release is a person doing something by hand?
3. If we shipped a bad change right now, how long until we’re back to working?
4. What’s our test coverage, and what breaks if we ship without running the tests?

A team in good shape answers all four in about a minute. A team in trouble gets uncomfortable, and that discomfort is your actual data.

Then pick the single slowest manual step and ask what it would take to automate just that one, not the whole pipeline. Usually it’s the deploy itself, and usually it takes a couple of days of work to turn into a script that runs on its own. The next slowest step gets easier after that, because someone on the team has now done it once and it stopped being scary.

One more thing, and it costs you nothing: ask to watch a deploy. Sit there while it happens. You’ll learn more in those twenty minutes about how your product gets built than in a quarter of status meetings, and you’ll know within five minutes whether this is a boring automated thing or an event where three people hold their breath.

What’s the smallest change your team has ever taken more than a week to ship, and did anyone ever tell you why?

#FractionalCTO #StartupTech #TechLeadership #SoftwareArchitecture