"Move fast and break things" was always bad advice. Breaking things is expensive. But moving fast? That's non-negotiable.
The question isn't whether to ship quickly — it's how to ship quickly without leaving a trail of incidents behind you.
The playbook
After years of building and shipping software for teams of all sizes, we've settled on a set of practices that let us move fast with confidence.
1. Automated testing as a prerequisite, not an afterthought
Tests aren't a nice-to-have. They're the foundation that makes everything else possible. Without them, every change is a gamble.
We focus on integration tests over unit tests. A unit test tells you a function works in isolation. An integration test tells you the system works as a user would experience it.
2. CI/CD that actually works
Your deployment pipeline should be boring. Push to main, tests run, code deploys. No manual steps, no "run this script first," no crossing fingers.
We use feature flags to decouple deployment from release. Code ships continuously; features activate when they're ready.
3. Observability from day one
You can't fix what you can't see. Every service we build ships with structured logging, metrics, and tracing from the first commit. When something goes wrong — and something always goes wrong — we know within seconds, not hours.
4. Small, frequent deploys
The riskiest deploy is the one with 47 changes bundled together. We deploy small changes frequently. If something breaks, the blast radius is tiny and the cause is obvious.
5. Blameless incident culture
When incidents happen, we run retrospectives focused on systems, not people. "Why did the system allow this to happen?" is a more useful question than "who caused this?"
The result
Teams that follow this playbook ship faster because they're careful, not in spite of it. They spend less time firefighting and more time building. Their weekends stay free.
That's the real velocity metric worth tracking.