The Gate system: how fixed-scope builds stay on time

Fixed-scope builds stay on time when delivery is split into gates: named checkpoints, each with defined inputs, one defined output and a single sign-off, where the next stage cannot open until the previous one closes. When a gate is blocked, the blocker is named the same day and given an owner, so delay is visible in hours rather than discovered in weeks. We use this structure to take an Outbound Engine from contract to live sending in 30 days, and it works for any fixed-scope project.

Why do fixed-scope projects run late?

Rarely because the work is too big. Most late projects contain roughly the right amount of work; what they lack is sequencing. Tasks sit in waiting states that nobody owns — copy "with the client for review", domains "being set up", a list "nearly done". Each waiting state looks harmless on its own. Stack five of them and a 30-day build becomes a 90-day build without any single moment where anyone decided to be late.

The second cause is the founder. In most small firms the founder is the default approval step for everything, so every project queues behind one inbox. I wrote about this at length in The Founder-as-Bottleneck Report: when every decision routes through one person, the constraint is not capacity, it is the routing. Gates attack both problems at once. They make waiting states visible, and they attach one named owner to each sign-off, so approval stops defaulting to the busiest person in the building.

What is a gate, exactly?

A gate is a binary checkpoint between two stages of work. It has three parts:

• Entry criteria — what must exist before the gate can be reviewed.
• An owner — one named person who signs it off. Not a committee.
• An exit rule — the next stage does not start until the gate closes.

The binary part matters most. A gate is either closed or it is open; there is no third state. "Mostly done" is open. This feels pedantic until you notice that "mostly done" is precisely where late projects live.

How does the Gate system run a 30-day build?

Here is the mechanism, using our own delivery as the worked example. When a client signs, the build is divided into five gates:

When Gate 1 closes, then infrastructure work starts — and not before, because domains bought before the offer is locked tend to get rebuilt. When Gate 2 closes, then warm-up runs in the background while the list is built, because warm-up typically takes two to three weeks whatever else is happening. When Gate 4 stalls, then launch moves day-for-day with it, and the client can see exactly why. No gate is skipped, and no stage starts on a promise that the previous one will close "any day now".

The timings flex. The sequence does not.

What happens when a gate stalls?

The stall is named, dated and owned within one working day. In our builds, most stalls are client-side — copy approval sitting in someone's inbox, a DNS access request unanswered. That is not a complaint; it is a design input. It is why we front-load every client request into the first week, which is really an onboarding problem — I have covered that separately in Onboarding: the first system a client feels. When everything you need from the client is collected before delivery starts, the gates that remain are yours to close.

Doesn't this add bureaucracy?

It adds roughly five written sign-offs per project. In exchange it removes rework, which is where fixed-price work actually loses money: building on an assumption that a later approval overturns. A sign-off email is cheap. Rebuilding a verified list against a changed ICP is not.

There is a second-order benefit. Publishing your delivery method is a form of proof of thinking before you have case studies. A prospect who can read exactly how you deliver, gate by gate, needs far less convincing than one shown a logo wall.

Does this only work for client projects?

No. The underlying rule — the next stage opens only when the previous one closes, and blockers are named the same day — scales down to a single person. How I run my week is the personal version: fixed blocks, binary done-or-not, no "mostly". If your projects drift, gate them. If your weeks drift, it is the same fix at a smaller scale.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.