Approval gates: why every project stage needs a documented output
Projects reviewed only at the end find their mistakes when fixing them has become expensive. An approval gate after each stage stops a mistake where it happens and gives the client real control.
There is a recurring pattern in software projects: the client explains what they want in the first meeting, the team disappears for months, and what is finally delivered is some distance from the expectation. At that point two options remain: accept the wrong thing, or pay again to fix it.
Approval gates exist to break that pattern.
What an approval gate is
The project is split into stages. Each stage has a documented output that the client reviews and approves. Until it is approved, the next stage doesn't begin.
It is simple, and it changes one fundamental thing: a mistake is found in the stage where it was made.
Seven stages and their gates
This is the structure I follow in my own process:
| Stage | Output | Gate |
|---|---|---|
| Understand | Problem map | The problem is the right one |
| Define | Requirements document, v1 scope | Scope and success criteria locked |
| Architect | System map, API contracts, data model | Architecture and risks accepted |
| Design | User flows, interactive prototype | Prototype signed off |
| Build | Phased releases | Each phase on a preview environment |
| Validate | Test report | All acceptance criteria passing |
| Launch | Live product | Live, with monitoring on |
Each output is the input to the next stage. The problem map leads to the PRD, the PRD to the architecture, and so on to the end.
Why a late mistake is expensive
The cost of fixing a mistake multiplies as the project advances:
- In Define: a sentence in a document changes.
- In Design: a few screens are redrawn.
- In Build: code is rewritten.
- After Launch: user data is involved as well.
Gates hold the mistake at its cheapest point.
What the client gets
- Real control. At each gate you can correct, stop or approve. Your commitment is stage by stage, not all at once.
- Visible progress. Instead of "eighty per cent done", there is a concrete output in front of you.
- Manageable risk. If the project has to stop, it stops at stage two, not month six.
- Documentation as an asset. At the end you own the product and every decision document.
What the team gets
- Less ambiguity. The team knows exactly what was approved.
- Change with rules. A new request mid-flight is weighed against an approved document.
- Less rework. Nothing is built that is later thrown away.
A gate is not bureaucracy
A common worry is that this slows the work. Done badly, it does. The difference lies in a few points:
- Short outputs. A document read in one sitting, not a book.
- Fast approval. A gate must not wait weeks for a signature. One named person with authority to decide.
- Clear criteria. What "approved" means is known in advance.
- Small steps in the build. The build stage is itself split into demonstrable phases; one big gate at the end of the build is the old problem again.
This doesn't conflict with agility
Approval gates don't mean planning everything in advance. The build stage can be fully iterative and flexible. What the gates guarantee is that before the build starts, the problem and the boundaries have been agreed.
Agility is about responding to what you learn, not about starting without thinking.
When requirements change
Requirements change during a project, and that is normal. With approved documents, a change is no longer a vague argument:
- The change is compared with the approved document.
- Its effect on scope, time and cost is made clear.
- A written decision is taken.
The tool that makes this traceable is the requirements traceability matrix.
This very site
The method isn't only advice. This site was built with the same seven stages: each produced a documented output, and its technical decisions are kept as architecture decision records.
The takeaway
An approval gate is a simple idea with a large effect: one output per stage, one approval per output. Mistakes surface early, the client stays in control, and nobody is surprised at the end.
For a project that needs order, see project and quality leadership.