Engineering · Published August 6, 2026
Gray Releases for Small and Mid-Sized Projects
Without heavy infrastructure, simple techniques still keep release risk under control.
Gray releases sound like something only large companies do. In practice, once you have more than a hundred users it is worth planning. Most of our clients run internal systems with a few hundred users, and this approach works for them.
Three levels of gradual rollout
By account: two or three departments get the new version first while others stay on the old one, limiting the blast radius.
By feature flag: new features ship disabled and open to selected users through configuration. If something breaks, turn the flag off instead of rolling back code.
By time window: release during off-peak hours and notify key users, never during month-end closing.
Two things that come with it
A release checklist covering database changes, configuration and dependency versions. If one item is missing, do not release.
A rollback plan that names who executes it, how long it takes and whether data can be reversed. Shipping without a rollback plan is gambling.
A gray release is not technical showing off; it is basic respect for the client's business. Half an hour of preparation saves a night of debugging.
← Previous post
A Full Post-Mortem of a Project We Should Not Have Taken
Next post →
Form Design: One Field Fewer, One Step More Completion
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →