Before we write any code, a problem goes through five gates. At the end we either build it or drop it, and we get there in weeks.
Nothing moves to the next gate until the last one is written down. The examples below follow a school-software field.
We choose a sector where the region has a real need and we have the engineers to meet it. The field gets a short brief: what we know, what we don't, and the questions worth answering. We only take on as many fields as we can carry to a finished product.
Leaves behind · a field briefWe go into the field. We interview the people doing the work, look closely at the tools they use now, and list where things break. This gate ends when we can state the core problem in one sentence that could be proven wrong.
Leaves behind · a one-page thesisA school keeps the same student in five systems that don't share data, so nobody sees the whole child.
We sit down with everyone the problem answers to: the regulator, the owner, the people who would use it every day, and whoever pays. They tell us what a solution has to do before they'd adopt it.
Leaves behind · an agreed solution shapeWe write down what we would build before we build any of it: the architecture, the data, who can see what, and what it costs to run each month. If the people at the table wouldn't use it, we keep working on it.
Leaves behind · a build spec and a business caseWe make the call and put it in writing. A Go moves to commercialization. A No-Go gets filed with everything we learned, and the field goes back in the queue for another look later.
Leaves behind · a signed decision memoMinistries, companies and universities hire us to run the same five gates on a problem of their own. You get a written decision in weeks. We only build if the answer is Go.
Every field faces the same four at the last gate. Flip them and watch the decision.