Process

How we decide a release is ready

The questions we ask before a build is allowed to reach real users.

Written by
Priya Nair, QA & Release
Published
Reading time
4 minutes

“Ready” is the least useful word in a release meeting. It means the tests pass, or the feature list is complete, or someone has run out of time. Those are very different states to be in on the morning of a rollout.

So the quality pod asks a fixed set of questions instead. Has every core flow been run against real operational data, not fixtures? Does the product behave when a dependency is slow rather than absent? Can we see, from production telemetry alone, that a user completed the thing they came to do? Is there a runbook for the three failures we consider most likely?

“Ready” is the least useful word in a release meeting.

None of those are pass or fail on their own. Together they turn a judgement call into a conversation with evidence in it, which is what makes it possible for one person to say “not yet” without it becoming an argument about confidence.

The other half is deciding what a release actually buys you. Often the right next step is a controlled pilot with one team rather than everyone at once. The gap between those two is where most of the risk lives, and naming it explicitly has saved us from at least one rollout we would have regretted.

Start a project

Got a problem software could solve?

Tell us what's slow or messy at your business. We'll reply within one working day and tell you honestly whether software can help.