Choosing project #8 by framework, not enthusiasm
The same triage math run before a line of code exists, on a project you don’t yet have six months of sunk enthusiasm invested in — the actual test of whether any of this was learned.
Everything the ledger holds was written down after the fact. Seven projects, each with hours already in it, a state label describing where it got stuck, a maintenance figure, a verdict, a revisit date. Every gate you have run so far was run backwards, against something that already existed and already had a claim on you.
That is the hard direction, and the course chose it deliberately, because it is the direction you were already standing in. But it is not the direction the framework is actually for. The gates exist so that the eighth project does not become an eighth row in that table — and the eighth project is the one that has not started yet.
The same list, run in the other direction
The gates page does not know or care whether the thing you are holding it against exists. Each entry is a question with a pass test underneath it, and the pass test is answered yes or no. Nothing in that structure requires a repository, a domain, or a line of code. You can open the page against an idea that exists only in your head.
So run it forward. Take a candidate you have not built — a real one, something you would actually consider — and go down the page top to bottom, answering each pass test as honestly as you would for a project already on the shelf.
Two things change when you do that, and they pull in opposite directions.
Easier: there is nothing to defend
The triage module put hours sunk out of bounds as an input to any decision, and then spent the rest of the course working around the fact that ruling a number out of bounds does not stop you feeling it. Every gate you have failed so far, you failed while looking at something you had already paid for. That is why the ledger keeps the hours in a table of their own, visible and explicitly excluded: a number you are pretending not to have is one you cannot argue against.
On an unbuilt candidate that entire problem is absent, and not because you got better at ignoring it. It is absent because there is nothing there. The hours column is zero. There is no half-finished thing whose existence quietly reframes every question as “should I throw this away” instead of “is this worth doing”. A gate that fails costs you the idea and nothing else.
This is the only moment in a project’s life when that is true, and it is worth being blunt about how short it is. The cheapest a decision will ever be to reverse is before it has been made once.
Harder: there is nothing to point at
The reverse is just as real. On a project that exists, a pass test can be answered by going and looking. What does it cost to keep alive? Open the bills and the commit history. Who is using it? Check. The evidence is lying around because the thing has been running.
A candidate has none of that. Every answer has to be assembled out of the world rather than read off the project, and some of the answers cannot be assembled at all yet. This is where the exercise stops being a formality, and where the cheating happens — not by answering wrongly, but by answering confidently about the things you cannot actually know, because a page of yeses feels like progress.
Sorting the gates — and this part is the course’s own
Where people get burned
What follows is the course’s reasoning, not a finding. I went looking for a named author who draws this line explicitly — who says outright that some criteria for judging a project are answerable before it exists and others are structurally not — and found support for one half of it only.
For the first half there is support: working founders describe methods for getting real demand evidence before any code is written, and two of them appear below. For the second half there is nothing to cite, because the second half is closer to a definition than to a claim. You cannot measure the upkeep of a thing that does not exist. You cannot observe what an activity keeps producing after you stop, if you never started. Nobody publishes that, the way nobody publishes a paper establishing that an empty box weighs less than a full one. Treat the sorting rule below as a tool, then, not as evidence.
The rule is a question you ask of each pass test on the page, rather than a fixed list of which gates are which:
Does this pass test ask me to measure something, or to find something out, or to decide?
Those three answers behave completely differently on an unbuilt candidate.
Find-something-out gates are fully available to you. Whether anyone is already charging for something like this, who would hand over the money, where those people already gather — every one of those is a fact about the world, and the world is there to be read and asked whether or not you have built anything. These are the gates the two sources below are about.
Decide gates are available too, and trivially so. A price you are considering, the arithmetic from that price to a target you set, a written verdict with a date on it, a commitment to one route to market: none of these are discoveries. They are choices, and you can make a choice about a thing that does not exist as easily as about one that does. Do not mistake how easy they are for how much they tell you. A decide gate passing is evidence that you made a decision, not evidence about the project.
Measure gates are the ones that are not available. Any pass test that turns on a figure you would have to take off the running thing, or on what is still true after a stretch of time with it live, is asking for a reading from an instrument you have not built yet. There is no honest way to answer those in advance, and knowing that is the skill this lesson is actually teaching.
The rule is worth preferring over a memorised list of gate names for a practical reason: the gates page is a living document and gates get added to it. A rule you apply to a pass test still works on a gate that was not there when you learned it.
Two people on getting demand evidence before you build
The find-something-out gates are not a hopeful assertion. Working founders describe concrete methods for answering them, and it is worth seeing more than one, because their biases are different and their methods agree anyway.
Jason Cohen: convergence, not approval
Cohen’s essay, published on his site on 26 June 2012, is about how to tell a real idea from a well-liked one before you commit. He describes an idea he researched before WP Engine on which, he writes, everyone told him it was a great idea — and then, as he pressed each person, “the ‘truth’ started diverging” into unrelated markets, unrelated prices, unrelated purposes. The WP Engine research went the other way:
“The more people I spoke with, the more agreement there was over the pain they had” (Cohen, A Smart Bear)
The test is not whether people say yes. It is whether their answers point at the same place. That is available to you entirely before building, and it is a sharper instrument than a page of yeses, because universal enthusiasm is exactly what the failing idea produced.
Cohen founded WP Engine and Smart Bear Software, so this is an operator writing rather than a coach. The same page carries a link to a book he sells and to a course he sells on an adjacent domain. Both halves are worth holding: a track record, and a site that monetises the writing.
Justin Jackson: name five
Jackson’s post, published 22 February 2014, is short and its whole method fits in a sentence: write down the names of five real people who need the thing.
“If you built this thing, who would buy it?” (Jackson, justinjackson.ca)
He is explicit that failing it is informative: not being able to reach five names is, in his words, a red flag. Note what the test costs to run — a piece of paper — and note that it is a strictly smaller version of a move the gates page already asks you to make about where your buyers are. If you cannot do the small version, the larger one is not going to rescue you.
Jackson later built Transistor.fm, a podcast hosting business, so he is an operator too. The page itself sells nothing at all, which is unusual enough among sources in this area to be worth saying plainly rather than implying a bias that is not on the page.
A prior question the gates do not ask
There is one thing worth settling before you open the page at all, and the gates do not cover it, because it is not about the candidate. It is about you.
Rob Walling’s essay argues for an order. Start with something simple that attaches to an ecosystem which already has buyers in it and sells for a one-time price; repeat or grow that until it covers the income you need; attempt the standalone subscription business only after that. His reason for the sequence is runway rather than merit — he notes that the recurring model has a long ramp before the revenue amounts to much, which is survivable once your time is already bought and brutal before. On the first step he is blunt about the failure mode:
“the biggest pitfall that trips up first-time product people is trying to create something too complex” (Walling, robwalling.com)
And on where to attach it: “It’s much easier to sell an add-on to an existing ecosystem”, his examples being marketplace add-ons where discovery comes with the marketplace.
What this is not is a way of judging a candidate, and it should not be borrowed as one. The essay never evaluates a single idea against criteria. It sorts kinds of business by which stage of your own finances they suit, which is a different question from the one the gates ask, and it is genuinely useful precisely because it is a different question. Ask it first, once: is this candidate the right shape for where I am? Then open the gates and ask whether this particular one holds up.
Where people get burned
Name what you are reading. Walling co-founded TinySeed, which his own about page describes as an accelerator for B2B SaaS — a fund that takes equity in companies founded by people following advice like this. He also runs MicroConf, a paid conference and community whose members are the exact audience for the framework, and sells books, a course and coaching from the same site. The success statistics on that about page are marketing copy for the accelerator and are not cited here.
The essay itself is unusually open about its evidence, which is the reason to read it rather than a summary. It says the pattern was noticed by watching founders, that the author wrote it down years before publishing because he did not yet have enough data to be confident in it, and it names the individual people it worked for. That is a set of examples chosen after the outcomes were known. It is real information and it is not a measurement, and the essay is straightforward enough to let you tell which you are being handed.
Not building is a pass, not a failure
Run the gates forward on a candidate and one of the possible outputs is: do not build this. That outcome is the exercise working. It is the cheapest verdict available anywhere in this course, and the only reason it feels like a waste is that nothing visible came out of it.
Compare it with what the alternative costs. The same verdict reached after building is the same verdict, arrived at with your hours in it and an artifact on a shelf that now needs killing properly, with a sunset plan and a line removed from a maintenance budget. Every project on your current ledger that you would not start again today is an instance of that more expensive route. The whole value of running the gates forward is that it produces the identical answer for the price of the exercise.
So write the verdict down even when it is no, and write it in the ledger rather than in your head. A rejected candidate that leaves no trace will be had again. Ideas recur, and the second time round it will arrive without the reasoning that killed it and with all of its original appeal intact.
One constraint carries over unchanged from triage: the cap on how many projects sit in pursue at once. A candidate that passes every answerable gate still does not get to join a full pursue list simply because it is new and the others are not. If nothing comes out, nothing goes in.
Retrieval check
You run the gates on the candidate and some of them cannot be answered, because their pass tests ask for a figure measured off something that does not exist. Has the candidate failed?
Check your answer
No, and it has not passed either. Those gates are unanswered, which is a third state, and the mistake is collapsing it into one of the other two. Marking them failed rejects a candidate for the crime of being unbuilt, which would reject every candidate. Marking them passed records a guess as a reading, and a pass test that asks for a real reading is not satisfied by a guess dressed up as one.
Write not answerable yet against each, and beside it the smallest thing that would have to exist for you to take the reading. Then decide on the gates you could answer, knowing exactly which ones you are deciding without.
Hands on
Run every gate forward on something you have not built
Done when: PORTFOLIO.md carries a new project section for one unbuilt candidate, in the same field shape as the existing seven, with every gate on the gates page answered yes or no or explicitly marked “not answerable yet” — never left blank — a written line beside each unanswerable one naming what would have to exist to answer it, and a dated verdict, including if that verdict is “do not build”.
- Pick one candidate you have not built and would seriously consider. A straw idea you already know you will reject teaches nothing — the exercise only bites when you would quite like the answer to be yes.
- Before opening the gates, write one line about shape: is this a one-time sale, something that could grow to cover your income, or a subscription? Walling’s ordering says attempt those in that sequence, on runway grounds. You are free to disagree with him, but disagree on purpose and in writing.
- Open the gates and work down the page in the order it lists them. Do not skip ahead to the gates you can answer easily — the order is what stops the answerable ones from standing in for the rest.
- For each pass test, first classify it: does it ask you to measure something, find something out, or decide? Write the classification down next to your answer. It is what tells you, later, how much the yes was worth.
- Answer every find-something-out gate from evidence you gather today, without writing code. Cohen’s test is the standard to hold yourself to: not whether people approve, but whether independent answers converge on the same pain, the same buyer, the same price.
- Where a pass test asks for a measurement off a live thing, write not answerable yet and, in one sentence, the smallest thing that would have to exist before you could take that reading. Those sentences are the most useful output of this whole exercise.
- Leave nothing blank. A blank and a “not answerable yet” look identical in a file read later, and they mean opposite things: one is a finding, the other is that you stopped.
- Add a new
###section for the candidate tolearning/monetizing/PORTFOLIO.md, using the same fields as the existing seven projects. The ledger has no convention for an unanswerable gate — you are adding one. Mark those fields rather than leaving them empty. - Record the state as an idea, and put a zero in the hours-sunk table. That zero is the entire argumentative advantage this candidate has over everything else in the file, and it will never be more accurate than it is today.
- Leave the actuals field empty and say why: nothing has been sold, because nothing has been built. Every other field in this exercise runs on estimates and research, which is the only thing this ledger has ever held.
- Write a verdict with today’s date. If it is “do not build”, write the reason beside it in one sentence, and treat the section as finished work rather than as a section to delete.
- Check the pursue cap. If the verdict is pursue and the cap is already full, name what moves out. A candidate cannot enter on the strength of being new.
- Bring the new section into the chat. I will push hardest on two things: any find-something-out gate answered yes without naming the evidence, and any gate marked “not answerable yet” that you could in fact answer without building anything, by asking somebody.
What this does not cover
You now have a candidate that has been through the gates before existing — some gates answered, some explicitly deferred with a note saying what would settle them, and a verdict with a date. That is the framework working in the direction it was built for.
What none of it uses is the thing sitting directly above it in the same file. The projects already in the ledger are not only a list of obligations; they are a record of how ideas actually go once you start them — which shapes you finish, which ones stall at the same point every time, how far your estimates land from what things turned out to cost. A gate answered by research tells you about the world. That record tells you about the person who is going to do the work, and it is the one input a stranger’s framework cannot supply. Reading it as evidence about yourself is what the course closes with.
Read this next — primary source
The Stair Step Method of BootstrappingRob Walling, robwalling.com — free; published 26 March 2015 per the page’s own structured data, though the visible byline prints only “Mar 26” with no year
Read it whole, because this lesson borrows it for one narrow job and explicitly refuses it a larger one, and a refusal like that is only worth trusting from someone who has checked it themselves. The claim to check is that the essay never evaluates a candidate against criteria anywhere in it. What it argues instead is an order: attach something simple to an ecosystem that already has buyers, repeat that until it covers your income, and only then attempt the standalone recurring thing. That is a claim about which stage you are at, not about which idea is good, and reading the middle section is how you feel the difference. Read it for its evidence too, which the essay is unusually open about: it names the people it worked for one by one, and it says in its own words how long the author sat on the pattern before trusting it. A list of names who did well is a real thing to have noticed and it is not a measurement, and the essay lets you see which one you are being handed.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.