The "move fast and break things" era is over — not because the sentiment was wrong, but because it was misread. The teams that actually move fast don't lower their standards. They remove the friction between having an idea and shipping it.
Here's what that looks like in practice.
Friction Is the Enemy, Not Process
Bad processes add friction. Good processes remove it. The goal is to distinguish between them.
Code review is process. It catches bugs before they reach production, spreads knowledge across the team, and creates accountability for what ships. This is good friction — it prevents more friction later.
A two-week sprint ceremony with six people in a room deciding what to prioritize is also process. For a team of three, it's pure friction — overhead with no value. Scrap it.
The question for every process is: what failure mode does this prevent, and is that failure mode more expensive than the process itself?
Deploy Often, Deploy Small
The single most impactful thing you can do to reduce deployment risk is to deploy smaller. A deployment with one change has one possible failure mode. A deployment with thirty changes has thirty.
This sounds obvious. Most teams don't do it — because it requires discipline, tooling, and a culture that treats small deploys as normal rather than lazy.
The infrastructure required for frequent small deploys:
- Branch-based preview environments
- One-command rollback
- Feature flags for risky changes
- Automated smoke tests that run in under two minutes
Once these are in place, deploying five times a day is lower-risk than deploying once a week.
Build in Observability From Day One
You can't ship fast if you don't know what's breaking. Most teams add observability after something breaks — which means they're always reacting, never ahead of the problem.
Minimum observability for a production app:
- Error tracking with real-time alerts (Sentry)
- Performance monitoring with response time p95 (Vercel Analytics or Datadog)
- Structured logs with a search interface
- Health check endpoint that verifies critical dependencies
With these in place, you know about problems before your users do. That's the prerequisite for shipping fast with confidence.
Write Tests That Actually Catch Bugs
"We need more test coverage" is one of the most common tech debt items I see — and one of the least useful without context. The question isn't coverage percentage. It's whether your tests catch the bugs that actually happen.
The bugs that actually happen are almost always in the integration between components, not in individual functions. A unit test that mocks the database will pass while a SQL query is silently returning the wrong data. An integration test against a real (test) database catches it.
For most web applications, the highest-value tests are:
- E2E tests for your three or four critical user paths
- Integration tests for API endpoints with a real database
- Unit tests for pure business logic with non-trivial branching
Don't chase 100% coverage. Chase coverage of the paths your users actually take.
Shipping fast is a system property, not a personal virtue. You can't just decide to move faster. You have to build the infrastructure — tooling, process, culture — that removes the friction between good ideas and shipped software.
That takes time to build. It's worth it.