Most CI/CD writing is by and for companies with platform teams, so small teams either copy a setup built for 200 engineers and drown in it, or conclude the whole thing is enterprise ceremony and keep deploying by hand. Both are mistakes. A team of three benefits from automated delivery more than anyone, because on a small team every hour spent shepherding a manual deploy is an hour of your total engineering capacity.
What follows is the setup we install at startups and small product teams, tuned for one thing: shipping safely with near-zero ongoing attention.
What a small team actually needs
- Every push runs the tests, and a red build blocks merging. Non-negotiable.
- Merging to main deploys to staging automatically, every time.
- Production deploys are one click or one command, by anyone on the team.
- Rollback is one command and under two minutes.
- The whole pipeline runs in under ten minutes.
That is the complete list. Multi-stage approval gates, release trains, change advisory boards: all of that exists to coordinate many teams sharing one system. With five people who talk every day, the coordination problem it solves does not exist, so the ceremony is pure cost.
The pipeline in four stages
- 1Build and lint: compile, type-check, lint. Fail here in under two minutes on the obvious mistakes.
- 2Test: the automated suite, run in parallel. This is the stage that earns the trust everything else spends.
- 3Package and deploy to staging: build the artifact once, deploy it to a staging environment that mirrors production shape, automatically on every merge to main.
- 4Promote to production: the same artifact, not a rebuild, promoted with one action. Tag it so you always know what is live.
Use whichever pipeline runner comes with your repository host. For a small team the built-in one is fine, and the worst choice is a self-hosted CI server that becomes a pet: we still get called about build servers that have not been upgraded since 2021 and that only one departed contractor understood.
Guard the ten-minute budget
Pipeline speed is not a vanity metric. Past about ten minutes, engineers stop waiting, start batching changes, and context-switch away, and batched changes are where bad deploys come from. Three tactics keep you under budget: cache dependencies between runs, run test files in parallel, and move the slow browser-level tests to a nightly run instead of every push. A suite of fast tests on every push plus a thorough nightly catches almost everything the all-on-every-push version does, at a fraction of the wait.
10 min
pipeline ceiling before engineers start batching changes
1
command to roll back production
2021
last upgrade on the oldest pet build server we rescued
Make deploys boring
The goal state is that a production deploy is so routine nobody announces it. Three practices get you there. Deploy the exact artifact you tested, never a rebuild, so what you verified is what ships. Keep the previous version warm so rollback is a pointer flip measured in seconds. And put feature flags around anything risky, so shipping code and releasing behaviour become separate decisions: the deploy goes out dark, and the feature turns on when you choose.
At Bloom Learning, a four-person team went from a fortnightly two-hour deploy evening to shipping eleven times a week within a month of this setup. The release evening did not get faster. It disappeared.
What to skip until it hurts
Skip multi-region deployment orchestration, canary analysis, service meshes, and internal developer platforms. These solve problems you will recognise instantly when you have them, and adopting them early costs attention a small team cannot spare. The honest upgrade path: add smoke tests after deploy when a bad release slips through, add canary releases when your traffic is large enough that five bad minutes hurts, and add approval steps only when a regulator or client contract demands one.
A pipeline like this takes one to two weeks to set up properly, including the test suite cleanup that usually comes with it, and then it mostly disappears from view, which is the point. If your team is still doing deploy evenings, our DevOps and reliability practice sets this up as a short fixed-scope engagement, and it pairs well with the cost hygiene we covered in cutting cloud spend.