Every team says it wants to move fast. Fewer teams are honest about what actually slows them down, and it is almost never typing speed. It is ambiguity, rework, long review queues and the fear of breaking something in production. The good news is that each of those has a known, unglamorous fix, and together they let you ship software fast without trading away quality.
- Batch size is the biggest lever on delivery speed: small changes are easier to review, test and roll back.
- Merge to the main branch every day and hide unfinished work behind feature flags.
- Make rollback a non event with reversible migrations and deploys that take seconds.
- Automate the checks that humans are bad at, so code review can focus on design and intent.
- Measure lead time, deploy frequency, change failure rate and time to restore, not lines of code.
Speed and quality are not opposites
The usual story is that you can have speed or quality, but not both. In practice, the teams that ship most often tend to have fewer production incidents, not more, because every change they ship is small enough to understand. A two hundred line change has a handful of ways to go wrong. A two thousand line change touching six modules has more failure modes than anyone can hold in their head during review.
So the question is not "how do we go faster?" but "how do we make each change small, safe and reversible?" Answer that, and speed follows as a side effect.
Small batches, always
The single biggest lever on delivery speed is batch size. Smaller changes are easier to review, easier to test and easier to roll back. They also keep the feedback loop tight, so you learn whether an idea works while it is still cheap to change.
We aim to merge something to the main branch every day, behind a flag if needed. That rhythm forces the work to stay small and keeps the team honest about progress. A ticket that cannot produce a mergeable slice within a day is usually a ticket that has not been understood yet.
How to slice work smaller
- Ship the data model first. Add the new table or column, unused, in its own change.
- Ship the read path before the write path. Display existing data in the new screen before letting users change it.
- Ship behind a flag. The code is in production but switched off for everyone except the team.
- Ship the boring edge cases last. Get the happy path in front of real users, then harden it.
Trunk based development and feature flags
Long lived branches are where speed goes to die. The longer a branch lives, the more it drifts from main, and the more painful and risky the eventual merge becomes. Trunk based development flips this: everyone integrates into one branch continuously, and unfinished features are hidden at runtime instead of in source control.
Feature flags are what make that safe. A flag lets you deploy code without releasing it, release it to a percentage of users, and switch it off in seconds if something looks wrong. Treat flags as temporary: give each one an owner and a removal date, or they become a second, invisible configuration system.
Make rollback boring
You can be brave about shipping only if going back is safe. Feature flags, database migrations that run in both directions and deploys that take seconds rather than hours turn a scary release into a non event.
The expand and contract pattern for database changes
Schema changes are where rollbacks usually break. The safe pattern is to expand first (add the new column or table alongside the old one), migrate reads and writes gradually, and only contract (remove the old structure) once nothing depends on it. At every step, the previous version of the application still works, so rolling back the code never strands the data.
- Add the new column, nullable, with no code using it.
- Write to both old and new columns; backfill existing rows.
- Switch reads to the new column behind a flag.
- Stop writing to the old column, then drop it in a later release.
Automate the checks humans are bad at
Code review is valuable, but people are poor at spotting a missing null check on line 412 or a dependency with a known vulnerability. Put those checks in the pipeline: type checks, tests, linting, dependency scanning and static analysis on every pull request. That frees reviewers to do what humans are good at, which is questioning the design, the naming and whether the change solves the right problem.
This is exactly why we built Caudilysis, our static code analysis product: one scan reports security, engineering quality and compliance together, so a pull request gets a clear signal before a human ever reads it. We wrote more about where automated analysis ends and human review begins in static code analysis vs code review.
Measure delivery, not activity
If you want to know whether your team is shipping well, four measures widely used in the industry (the DORA metrics) tell you more than story points or commit counts:
| Metric | What it tells you | Healthy direction |
|---|---|---|
| Deployment frequency | How often working code reaches production | Up: daily or more |
| Lead time for changes | Time from commit to running in production | Down: hours, not weeks |
| Change failure rate | Share of deploys that cause an incident or rollback | Down |
| Time to restore | How quickly you recover when something breaks | Down: minutes |
Speed and stability show up on the same dashboard. A team that improves deployment frequency while change failure rate rises is not getting faster; it is accumulating risk.
Where teams go wrong
- Big bang releases. Months of work merged at once, with a release weekend to match.
- Manual QA as the only gate. Valuable for exploration, too slow as the primary safety net.
- Flags that never die. Old flags make every code path harder to reason about.
- Skipping observability. If you cannot see errors and latency per release, you cannot ship confidently.
Frequently asked questions
How often should a software team deploy to production?
As often as the team can do it safely. Many healthy teams deploy several times a day; others deploy weekly. The number matters less than the trend: if deploys are getting smaller and more frequent while incidents stay flat or fall, delivery is improving. If releases are monthly events that need a weekend, batch size is almost certainly too large.
Do feature flags slow down the codebase?
Only if they are never removed. A flag adds a branch to the code, so dozens of stale flags make behaviour hard to reason about. Give every flag an owner and a removal date, review open flags in planning, and delete the code path that lost once a rollout is complete.
Is trunk based development safe for regulated products?
Yes, and it often makes audits easier. Every change is small, reviewed and traceable to a ticket, automated checks run on each pull request, and releases are controlled with flags and approvals rather than long lived branches. The controls move from the branch structure into the pipeline, where they are consistent and logged.
Habits that compound
None of this is exotic. It is a set of habits that compound: small batches, one main branch, flags for unfinished work, reversible migrations, automated checks and a handful of honest metrics. Put them in place early and speed stops being a trade against quality. It becomes a product of it.
If you are planning a new product and want these habits from the first sprint, our custom software development and SaaS development teams work this way by default. Or start with a free assessment of where your delivery process stands today.
