IBKIbukun Ogunnaike

Writing / Delivery · 1 min read

Ship it to yourself first

How per-account beta flags and launch-day readiness make releases boring, in a good way.

At ReelUse, every new feature takes the same path to customers. It ships behind a per-account beta flag, we prove it on our own internal accounts with real workloads, and then it goes to everyone, with help content and support answers ready on launch day.

Why per account

A global switch is all or nothing. A per-account flag lets us turn a feature on for exactly the people who should see it first, starting with ourselves. It also gives us a clean way back: if something isn't right, it's off for those accounts and nobody else noticed.

Why real workloads

Demo files are polite. Real recordings are long, messy, oddly encoded and full of edge cases. A clipping feature that's perfect on a clean five-minute test can behave very differently on a two-hour livestream replay. So internal testing means running the kind of work customers actually send.

Launch day is a readiness check, not a code deploy

By the time a feature goes to all customers, three things have to be true:

  • It has held up on real workloads in internal accounts.
  • Help pages, feature pages and support answers are updated in the same change.
  • The What's New entry and changelog line are written, plus a dedicated page if it's a major feature.

If any one of those isn't ready, we don't launch yet. That rule is what makes releases predictable.

The quiet benefit

Staged releases sound like they slow you down. In practice they speed up the next decision, because by launch day you already know what works, what needs attention and what customers will ask. Boring releases are the goal.

Related case study: Leading product at ReelUse

Keep reading

All writing