How Small Teams Should Think
About Releases

The two operations

Most release pain comes from conflating two operations that don't have to happen together:

• Deploy — moving code into the production environment.
• Release — making that code visible/active for users.

In a traditional release model these happen at the same moment, which is why "release day" is terrifying: you are simultaneously taking the deployment risk and the user-facing-change risk, against work that has been merging branches for weeks. Decouple them, and each becomes individually small.

The mechanics: four moves

1. Dark launch

Code lands on main behind a feature flag, off by default. It deploys to production with the next CI run — usually within minutes. The user sees nothing. You can verify the code in the real production environment, with real data, before any user is affected. "Works in production" is no longer a leap of faith — it is a precondition for the release decision.

2. Internal flip

Flip the flag for yourself and the team only (by user ID, by email domain, by an "internal" segment). Use the feature for real work. This is QA done in the only environment that matters — production — without exposing users to anything you haven't yet seen yourself.

3. Gradual rollout

Flip the flag for 1% of users, then 10%, then 50%, then 100%. Watch error rates, latency, conversion, and any business metric that matters. Hold or roll back if anything regresses. The release is now a knob, not a button — and a knob you can turn either direction at any time.

4. Flag retirement

Once the feature is at 100% and stable for a week or two, delete the flag and the dead branch of code it gated. The feature is not "done" until the flag is gone. Otherwise the codebase silently accumulates dormant flags, each one a future "wait, what does this do?" moment.

The traditional model vs. SSD-style releases

When the model breaks

Continuous-release thinking doesn't apply universally. It breaks for:

• App store releases — the store imposes its own gating and review cycle. Use feature flags inside the binary so you can still release server-controlled features daily.
• Regulated environments — medical, avionics, some financial — where formal change control is a legal requirement. The discipline still helps internally; the public release rhythm is constrained.
• Enterprise customers with contractual release rhythms — ship continuously to your own environments; cut named "versions" only when contracts demand it.
• Embedded firmware — the deploy step itself is expensive and risky. Different problem.

Further reading

• Shippable States Development
• The Simplest Engineering Lifecycle That Actually Works
• The Solo Developer's Engineering Manifesto
• Code Quality Without a QA Team: The Ratchet Principle