The three gates: how we decide something is ready

Ready is a word that causes a lot of damage. A developer means the code runs. A founder means they are tired of looking at it. A customer means it will not let them down. We use three gates so that the word always means something specific, and so that the decision to move on is made on evidence, not mood.

Gate one: ready for testing

The question is whether it works, end to end. Core features have to work from the first screen to the last, not just in pieces. Every task has to have been tested independently, by someone other than the person who built it, because builders see what they meant to build. And the privacy basics have to be in place: we collect only the data a feature needs, and each customer's data is kept apart from everyone else's.

In practice we ask three things of each task. Does it do what the plan says? Can it be broken by someone trying? Does it behave sensibly when something goes wrong, such as a lost connection or an empty screen?

Passing this gate does not mean the product is good. It means it is worth other people's time.

Gate two: ready to launch

The question is whether real people have used it without finding anything serious. Testing with real users runs for weeks, not days, because the problems that matter often show up only after several days of use. Alongside that, every security check has to pass, the code is independently reviewed, the privacy policy is live and the release is signed off by a person who is accountable for it.

Some products need more than this. Where the subject is sensitive, such as health guidance for parents, we also want qualified review of the wording before anyone relies on it. A gate can have extra conditions, but never fewer.

Launch is deliberately small. We release to a small group first, watch what happens and widen from there, so a mistake that slips through reaches few people.

Gate three: ready to scale

The question is whether it earns its keep. Steady weekly use shows that people come back, and paying customers show it is worth money to them. Only then does marketing spend begin. Advertising an unfinished product buys you more disappointed people, faster, and it hides whether the product itself is working.

Each product sets its own numbers for this gate, because a family app and a business product will not look alike. What matters is that the numbers are agreed before launch, not chosen afterwards to fit the result. We also ask each week what users struggled with and what we changed. A product that is never improved is not scaling; it is waiting.

What a gate is for

A gate is only useful if it can say no. Ours do: a release that fails a gate goes back, however close the date is. The cost of waiting a week is small and known; the cost of a bad launch is neither.

Write the criteria as things anyone can check, such as “no open serious defects” rather than “feels solid”. If two people could disagree about whether a criterion has been met, it is not yet a criterion.

The same applies to client work. Stage gates on a project give a sponsor a point to stop, change course or continue with the facts in front of them. Define the evidence for each gate at the start, make the decision in the open, and write down what was decided and why. None of this is complicated. The discipline is in refusing to skip it when you are tired and the date is close.

If you want gates that work on your own projects, talk to us.