The shelf, honestly stated
An honest inventory of what you’ve built, not what you meant to build — and why sunk hours are the one column you’re not allowed to weigh.
Seven projects, and no revenue from any of them. That is not seven separate problems — it is one problem, encountered seven times, and this course runs the same gate cycle against every one of them and then against the next thing you build. It starts here, with a page that does nothing except tell the truth about what is already on the shelf.
Not what you meant to build. Not what it will be once you find a weekend for the last few features. What is actually true right now, for a finished sports-guides site with zero visitors and for a half-built recipe app for kids alike.
What the shelf actually is
The shelf is a ledger — one file, learning/monetizing/PORTFOLIO.md, tracked in git rather than kept in your head or scattered across browser tabs. Markdown in version control beats a spreadsheet or a notes app for exactly one reason that matters here: it is diffable, so a verdict you change in three months is a change you can actually see, not a memory you have to trust.
It is not a to-do list and it is not a retrospective. A to-do list tracks what is left; the shelf tracks what is, as of today, independent of what you plan to do about it. That distinction matters because this course adds one judgment at a time from here — demand, cost to keep alive, a verdict — and every one of those judgments needs somewhere honest to land. This lesson is what makes the landing honest.
The four facts you record per project
Per project, four things, no more. Resist the urge to add a fifth before you have even filled in the first four — every extra field is somewhere to hide from an honest state label.
- What it is — one line. The shape of the thing, not its pitch.
- State — one label, from the set below. Not a paragraph explaining the state; a label.
- Hours sunk — a number, your best honest estimate if you never tracked time. Recorded, and then fenced off — the next section is about why.
- Last touched — roughly when you last worked on it. “In progress” and “untouched since spring” are different facts, and the label alone hides the second one.
Why hours sunk is recorded and then fenced off
Hours sunk goes in the ledger for one reason only: it becomes the material for a reference class about your own conversion rates and your own maintenance habits, later, once there are verdicts to look back on. It has no other job. Specifically, it is not allowed to push today’s state label, and later it will not be allowed to push the verdict either — pursue, park, or kill has to come out the same whether a project cost twenty hours or two hundred.
That restriction exists because the pull the other way is real and measured, not hypothetical. Arkes and Blumer randomly sold Ohio University Theater season tickets at full price or at a discount, then watched who actually showed up. Over the first half of the ten-play season, the full-price buyers used significantly more of their tickets (mean 4.11 plays) than either discounted group (3.32 and 3.29) — people who had paid more felt more pull toward using what they’d paid for, independent of how much they wanted to see the play. A ticket already bought carries no information at all about whether tonight’s play is worth the drive. It moved behavior anyway.
Two hundred sunk hours on a project are the same shape of ticket. They tell you nothing about whether that project is worth pursuing from here — the honest signal for that comes from demand and maintenance cost, not from how much you have already spent — but they will pull at the verdict exactly the way a full-price ticket pulled at attendance, if you let them anywhere near the decision.
Retrieval check
Without scrolling up: what did the discount actually change in the Arkes & Blumer theatre study, and for how long did it change it?
Check your answer
It changed how many of the ten plays people showed up for — not whether they enjoyed the plays, which nobody measured, but whether they used the tickets they already owned. Full-price buyers averaged 4.11 plays across the first half of the season; the $2-off and $7-off groups averaged 3.32 and 3.29, both significantly lower.
And it faded: by the second half of the season the three groups were statistically indistinguishable (2.28, 1.84, 2.18). The pull sunk cost exerts is real but it is not permanent or automatic — which is exactly why fencing it off in writing, once, is cheaper than relitigating it every time a project comes up for a verdict.
The honest state labels
“In progress” is where most shelves lie, because it is true of almost everything and specific about nothing. Use one of these five instead:
- Idea — no code exists yet.
- In progress — code exists and does not yet do the thing end to end. A half-built recipe app for kids lives here.
- Built, unlaunched — feature-complete, and no stranger has ever been able to reach it. Nothing has been deployed anywhere a stranger could find it, on purpose or otherwise.
- Built, live — deployed and reachable right now, whether or not a single stranger has actually shown up. A finished sports-guides site with zero visitors is built, live — the code shipped and the distribution never did, and those are two separate failures with two separate causes.
- In testing — reachable only by people you invited, not the general public. Used deliberately for anything in a sensitive category where a wide-open launch would be premature.
“Built, unlaunched” and “built, live” look like the same achievement from the inside — the code is done either way — and they are not the same project. One of them has already paid the cost of finding out whether distribution works and gotten a real answer (zero, so far); the other has not paid that cost yet and the question is still open. Collapsing both into “built” erases the one fact the verdict lesson most needs.
Where people get burned
The self-flattering move here is not lying about hours sunk — it is picking the state label that makes the project sound further along than it is. “Basically done” for something in progress, “launched” for something built and unlaunched. Every label you round up is a project that gets judged on fiction once it comes time to hand down a pursue, park, or kill verdict.
Now build the first version of the shelf
Hands on
Fill in the ledger for all seven projects
Done when: Every project has an honest state label from the five above, and hours sunk is recorded for all seven — with no verdict column yet.
- Open
learning/monetizing/PORTFOLIO.md— create it if it does not exist yet — and start a summary table with a row for each of your seven projects: project, state. - Fill the state column using one of the five labels above, not a sentence. If you catch yourself wanting to write a qualifier next to the label, that is a sign the label is wrong, not that the project needs an asterisk.
- Add a second table, hours sunk: one row per project, one number each. A rough bucket is fine if you never tracked time — round numbers are still honest numbers when they are your real best guess.
- Do not add a verdict column. That is not a placeholder you are leaving for later; it is the actual constraint this lesson is teaching. You do not have the demand, maintenance, or arithmetic facts yet, and a verdict made without them is a guess wearing a verdict’s clothes.
- Reread the hours-sunk column once. Notice whether your attention snags on the largest number and starts building a case for it. That snag is the Arkes and Blumer effect, arriving on schedule — naming it is enough for today.
- Bring the two tables into the chat. I’ll check that all seven projects have a real label from the set above rather than a rounded-up one, and that nothing in a verdict column has snuck in early.
What this does not cover
The shelf now says what each project is and how much it has cost you so far, and it deliberately says nothing yet about whether any of them deserve more time. State and hours sunk are not evidence of demand — a project can be built, live, and completely unwanted, which is precisely the shape of the purest case on this shelf. The demand lesson goes looking for the signal that actually matters: finding out whether somebody is already charging for the thing you built.
Read this next — primary source
The Psychology of Sunk CostHal R. Arkes & Catherine Blumer, Organizational Behavior and Human Decision Processes 35 (1985), 124–140 — paywalled, abstract only without institutional access
Read it for Experiment 2 specifically, not the paper as a whole — Experiment 1 is an unrelated hypothetical about a ski trip. The first sixty people buying season tickets to the Ohio University Theater’s 1982–83 season were randomly sold a ticket at full price, at $2 off, or at $7 off. Over the first half of the season the full-price buyers attended more plays (mean 4.11) than either discounted group (3.32 and 3.29) — a real, tested difference that tracked what people had paid, not how much they liked the plays. That is the entire mechanism this lesson fences off, in one clean result. It is also honest about its own edges: the difference had vanished by the second half of the season, and the paper says so plainly rather than quietly dropping it.
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.