CI/CD for small teams: ship daily, sleep nightly

Before we had pipelines for the platform, we had a person. A careful, experienced person who knew the deployment steps by heart. That's the most dangerous infrastructure a startup can have — because knowledge that lives in one head doesn't scale, doesn't take holidays, and doesn't survive a resignation letter.

A deploy should be so boring that a junior engineer can do it on their first Friday. That's not recklessness — that's the goal.

The pipeline, minimally

Our rule was: every stage must earn its place by catching a real class of failure. The result is short:

1. On every push — lint, unit tests, build. Under ten minutes or engineers stop trusting it and start bypassing it.
2. On merge to develop — automatic deploy to a staging environment that mirrors production shape, not production size.
3. On release — one-click deploy to production, with the database migration run as an explicit, logged step.
4. After deploy — automated smoke checks on the endpoints a school hits first thing in the morning.

SOPs are the other half of CI/CD

Tools automate the happy path; SOPs handle everything else. When we formalized department-wise SOPs across development, support and operations, the biggest win wasn't speed — it was that incidents stopped being improvisation. Who rolls back, who informs support, who talks to the affected school: decided in advance, in writing, while everyone was calm.

What small teams should skip

Honesty about scale saves months. We skipped canary deployments, service meshes, and multi-region failover for years — not because they're bad, but because our failure modes didn't justify their complexity yet. Match your pipeline to your actual risk, not to a conference talk.

The measure of success is mundane: deploys per week went up, deploy-related incidents went down, and nobody's weekend plans depend on a release anymore. Ship daily, sleep nightly.