Four gates: how I decide whether a thing may move on

"Good enough" is a false signal

I keep several things running at once: a data annotation business, a data analysis shop that is preparing to launch, a few WeChat accounts, a survey system under development, and a set of handbooks I assembled myself. Every one of them moves. None of them moves all the way.

For years the explanation I had for that state was not enough energy. The explanation turned out to be wrong. The awkward part was that I had no standard for deciding which thing should move on and which thing should stop. Without a standard a person picks the easiest thing: rewrite the document, adjust the interface, look up more material, think about it some more.

In recent years I replaced the question "may this move on" with four questions that can be answered on the spot. Four gates, one at a time.

I used to judge by activity: code changed yesterday, three rounds of discussion this week, two thousand words of documentation. Any movement counted as progress.

That way has two holes.

Movement can be unlimited. A thing can be reworked for half a year, changed every day, and never used by another person once. Editing code, editing wording, editing colours: all of it produces the feeling of being in progress.

On the other side, the closer a thing gets to delivery the easier it is to polish in place. The last stage has the smallest changes and the fastest feedback, so it gets touched again and again.

So I replaced the question with this one: what can this thing show another person right now.

If there is something to show, move on. If there is not, go back and fill it in. The question does not care whether I am tired, whether I feel like it, whether I have inspiration. It only asks whether there is a thing.

The four gates were first set up for projects done with AI, to stop it writing carelessly and skipping steps. After a while it became clear that the one being governed was mostly me.

First gate: can the direction be explained to someone outside the trade

The first gate covers the opening stretch. Passing it requires all of these:

• A charter document that states what the thing is, who uses it, what problem it solves, what the first version does, and what the first version does not do.
• A feature list walked through from three angles: roles, business flow, modules.
• A stage plan whose first stage is the smallest version that runs the core flow.
• A stack note that says why this choice, and why not the other three common options.
• An architecture document that fixes directory rules, interface rules, error handling.
• A rules file for the AI, containing prohibitions and acceptance criteria.

The test is simple: find someone who does not work in this trade and talk for three minutes. If they ask "how is this different from XX", the difference has not been made clear. If they nod and say "got it, so it is the thing for whoever", the gate is passed.

I have stuck on this gate many times, always in the same way: treating "we discussed it" as "we have it". Three hours of talking with an AI, everything perfectly clear in my head, not one file written. Next session starts empty, so the clarity is void, and the talk starts over and comes out slightly different.

So I added a rule: no matter how clear the discussion, no file means nothing. The files are for the next version of me, and they are for the AI. An AI does not remember yesterday; it can only read what is in front of it today.

Second gate: did it actually run once

The second gate covers the skeleton, and the requirement is that several separate things each work once.

• The frontend starts, the home page opens, and the colours, type sizes and spacing from the design spec are live.
• The database connects, tables get created, a row goes in, a row comes back out.
• Four backend lines work: the service starts, a sample endpoint responds, business logic writes one real record, logging and error handling behave.
• The frontend calls the backend successfully: cross-origin (whether the browser may request the backend at all), response shape, and failure cases all line up.

The only evidence for this gate is commands and output. One start gives one log; one query gives one result set.

What this gate stops is "designed completely, never run once". I had a long stretch of that: architecture documents getting more detailed by the week, directory plans, error codes, log levels, permission entry points all thought through, and not one line executed. The world inside a document stays tidy because it has not met anything real.

The problems a single real run produces are mostly absent from the design: port already taken, timezone mismatch, field type disagreement, cross-origin blocked, connection pool too small. Those only surface by running. No amount of documentation replaces that one start.

Third gate: does the core path go end to end

Once the skeleton runs, features get added one by one. This gate wants the whole path walked, and it wants nothing else broken by the walk.

• All P0 features (the part the first version must have) are done.
• Every development round leaves an acceptance record with command, output and log.
• The full path runs from the first step to the last, each step really connected.
• Neighbouring features are regression checked, not broken by this round.
• Permission and input validation are examined: who may call this endpoint, what an over-privilege request returns, whether user A can reach user B's data.
• Key operations leave logs.

Judge by the path, not by the endpoints. Each endpoint returning 200 is easy; one path from the first step to the last is hard, because somewhere inside it you meet state, permissions, data ownership and failed rollbacks.

My usual shape on this gate is "half the demo works". The first half is clickable, the second half is next week. Next week something else jumps in and the second half stays there forever. A demo needs one watchable stretch; a product needs the entire line.

Fourth gate: is anyone really using it

The last gate asks the hardest question: is someone using it, has it produced one real result.

Four things are needed:

• The pre-release overall check has no blocking issue.
• It actually went live.
• A retrospective was written.
• At least one lesson from this round was written back into my own tool library.

The third and fourth are additions I made myself. Without a retrospective the next project steps in the same hole; without writing back, this round's lesson stays only in memory and is gone in two months.

This gate is the hardest because it requires other people. The first three gates I can satisfy alone in front of a screen. This one needs someone to actually come in, actually use it, actually pay once, or actually take away one deliverable. Whether other people take part is not my call.

So it is also the gate I have skipped most often, and the skipping looks respectable: the project is still being finished, wait for the slow season, wait until this interaction is better. I have said these things to myself many times. Each time they hold up, and each time the effect is the same: the thing sits between the third gate and the fourth.

What the gates really stop is skipping

Laid out in a row, the four gates stop the same movement: jumping from an idea straight to polishing.

Walking the whole sequence costs three kinds of pain. Explaining means getting questioned. Running means handling errors. Handing it to someone means hearing "this is not what I pictured". None of those three produce good-looking feedback.

Polishing produces feedback, and immediately. Nudge the interface and it looks better at once; revise the document and it reads tidier at once. Without a standard for judging, a person automatically takes the path that pays feedback. A year can pass that way with nobody stopping, and it looks like being busy.

The gates exist to block that path. Want to change the interface: first ask whether the skeleton runs. Want to improve the experience: first ask whether anyone uses it. These two questions are a buzzkill, and they saved me from a lot of redecorating inside the third gate.

The order cannot be swapped

I also tried the shortcut: simplify the early gates and charge straight at the last one. I tried it, and the cost doubled.

Move on without the first gate and every later round changes direction. The AI writes a pile of files against a vague direction; when the direction changes, all of them are rework, and during rework you cannot tell which few are still usable.

Add features without the second gate and the problems pile up until integration day, then appear together. Fields, permissions and response shapes all disagree, and one bug takes ten places to trace.

Ship without the third gate and the first real use becomes the first real test. Lucky, you lose one user. Unlucky, you lose a batch.

The gates have an order. While an earlier one is unpassed, the later ones do not count. Risk accumulates: a gap left early gets amplified downstream.

Gates can also be papered over. To pass the first gate, write six files of two empty pages each: apparently complete, actually nothing. I have written that kind of filler file myself.

The way to judge is to interrogate the files. That line in the charter saying what problem is solved: does it survive three rounds of follow-up. That item in the feature list: can you say who uses it, what goes in, and which branch an error takes. Files that go empty after two questions were not written.

The gates gave me one more thing: permission to stop

I used to be unable to stop. Stopping meant admitting failure, so I preferred to keep moving, moving anything.

Now there is a neutral way to say it: this gate is unpassed. The sentence does not judge me, it names what is missing. Missing files, write files. Missing one start, go start it. Missing users, go ask one person.

That phrasing works better than both "I think it is nearly there" and "I think it is not ready". The first makes people celebrate early, the second makes people delay forever, and neither produces a next step. "This gate is unpassed, what is missing is a start log" produces a next step.

How I use them now

When I want to open a new direction I ask two questions first: which gate is it standing in front of right now, and how many of the four gates am I willing to pay.

The answers often put the idea back down. One thought walking from zero to the fourth gate means writing files, getting it to run, walking the path, and finding the first person who uses it. Opening a direction used to cost nothing but imagination, so I opened many. Now I can see the price, so I open fewer.

I used to think I was running several things in parallel. I was starting several things. After opening fewer, the ones in my hands actually began to move. What this system did is make me open less; it never made me faster.

If I cannot say which gate a thing is standing in front of, it has not started. It has only been discussed.