The build trap is two problems, not one

Why "stop building" advice keeps failing you, and which half of the trap a writing discipline can actually fix.

TL;DR. The build trap is two distinct failures the literature treats as one: a clarity deficit (you cannot name who the work is for) and a stopping-power deficit (you can name it, and you ship the wrong feature anyway). A writing discipline solves the first half. Nothing in print solves the second. Most "stop building" advice fails because it aims clarity tools at a stopping-power problem.

Tuesday, 11pm. You are thirty-two. You have shipped eight products in five years; two are still up, neither pays a bill. You read Eric Ries in 2018. You have tried Notion, Linear, Things 3, time-boxes, build-in-public, no-build-in-public, a co-founder, no co-founder. You search "build trap" again and the results are the same as in 2022: do customer discovery, validate before you ship. You have done all of that. The ninth product is going to die anyway, and you can feel it.

This article is about why.

The distinction

The thing the productivity-and-discipline literature calls "the build trap" is two problems, not one. They produce the same surface symptom: you ship work, the work does not land, you ship more. They have different mechanisms and different solutions. Confusing them is the reason most "stop building" advice does not work on you.

Half of the build trap is a clarity deficit. You cannot say who the work is for. You sit down to write your landing page and the headline is "for solo founders." Two weeks later it is "for indie builders." Six weeks later it is "for anyone who has tried to ship a SaaS." The recipient drifts because there is no recipient. You do not know who is supposed to recognize themselves in what you built, so you cannot tell whether anyone has.

Half of the build trap is a stopping-power deficit. You know exactly who the work is for. You have known for six months. You know what you should be doing instead of building. You watch yourself open the editor at 11pm on a Wednesday and ship a refactor on a product nobody uses. The move is to call the three people from last month who said the demo was interesting. You ship the refactor anyway.

The first is a writing problem. The second is not.

A writing discipline forces you to name a person, name what changes for them, name how you would know it landed. It will not solve the second half. The second half is what happens after you have already named the person and you keep building features they did not ask for instead of talking to them.

The literature treats these as the same problem. They are not. This article is about how to tell which one you are in, on each of your past projects, and what each one responds to.

Half one: the clarity deficit

A clarity deficit feels, from inside, like a vocabulary problem. You know there is a customer. You know the customer has a pain. You know your product addresses the pain. You sit down to write the one-line description and the words come out vague. The third draft is the second draft with synonyms.

The drafts are vague because the thing they describe is vague. The recipient does not exist as a person in your head; the recipient exists as a category. Categories cannot do anything. Only people pay you, refuse to use your product, churn, or write angry emails. Your category is too big to fit any specific person inside it.

The clarity deficit has four shapes that recur in the pain dossier.

The expert who assumed self-as-recipient

Rachel Draelos shut down Cydoc, a bootstrapped health AI startup, after seven years. She is an MD who built the product for medical students. She talked to medical students. They liked the product. She kept building.

I assumed I was my own target customer... I thought that because I was a medical student and then subsequently an MD, I was representative of my target customer.

Rachel Draelos, Glassbox Medicine, Feb 2026

When I thought our product was for medical students, I talked to my medical student friends and they all said it sounded nice, but I didn't talk to any medical students from other institutions who could've given me impartial feedback.

(same source)

Late in the cycle, after a pivot to mental-health practices, she had this exchange with a practice owner:

"But didn't you tell me last year that your practice has fifty clinicians?" The owner replied, "Yes, but 47 of them are therapists who won't be using this particular product." I felt punched in the gut.

(same source)

She had built for 3 of 50 clinicians at the most promising buyer she had. The diagnosis was not sales or engineering. The recipient had been a hallucination for seven years. The writing she did at the start named the wrong person, and she never re-checked it against a real stranger outside her network.

This is a clarity deficit in its most credentialed, most committed, most expensive form. The person was wrong from sentence one and nothing downstream could catch it.

The buyer-versus-user confusion

Sam Stone of Ansaro names the same shape from the B2B side:

We spent a lot of time talking with our buyers: CHROs and Heads of Talent Acquisition... So we built a product for these buyers, not the recruiters who had to use it on a daily basis.

Sam Stone, Semi-Random Thoughts, Reflections on a failed startup

The problem we set out to tackle, reducing turnover and improving new hire performance, was felt acutely by our buyers (CHROs / Heads of Talent). It was NOT felt acutely by our users (recruiters).

(same source)

Recruiters are measured against average time-to-hire, not new hire retention or performance. We were trying to improve outcomes about which users would pay lip service, but which didn't impact their paychecks or promotions.

(same source)

Stone could pass a sharp recipient-naming check on "CHROs and Heads of Talent Acquisition." His clarity deficit is subtler: he named the buyer and treated the user as already-named-implicitly. The user had a different success metric, structurally indifferent to the buyer's, and refused to adopt. The unexamined assumption was that "the customer" was one person when it was two.

A writing discipline catches this if it asks "is there exactly one recipient, or are there two with divergent success metrics?" Most do not.

The vague-target shape

I assumed my audience was "everyone who uses software." That's not a target market. That's a wish.

Anonymous, Indie Hackers

Most indie founders doing $0 aren't distribution-constrained. They're specificity-constrained. "Founders" is not a target audience. "Solo founders using Notion to manage client projects" is.

pradeepbisht, Indie Hackers

This is the textbook clarity deficit. Lean Startup, Lean Canvas, the JTBD canvas, the customer-discovery scripts, and every persona-template Notion page are best-equipped to catch it. Writing disciplines work hardest here. They force the question "who specifically" and they will not accept "founders" as the answer.

The recipient-versus-where-you-spend-time gap

Pratham Naik shipped a product he spent six months validating inside the indie hacker community:

I'd spent six months in indie hacker communities asking what features people wanted... The indie hacker community is amazing for support and learning. But it's a terrible place to validate most products.

Pratham Naik, Indie Hackers

His first non-builder customer, a marketing agency owner, asked within five minutes for features he had built none of. Jack Builds describes the same shape:

I was posting where founders hang out, not where my customers hang out. r/SaaS is full of other builders, not buyers.

Jack Builds, Indie Hackers

This is the version of the clarity deficit you are most often in. The place you spend time online has been selected by your preferences and a recommendation algorithm. The community you can reach is the community you keep validating against. You name "small marketing agency owners" on the landing page. You never talk to one.

A writing discipline catches the front half of this (the naming) and not the back half (the reachability). If you have spent eighteen months on IndieHackers and your real recipient is in your local Chamber of Commerce, no amount of polishing your Q1 will fix the structural fact that you cannot get the artifact in front of them.

What writing disciplines do for the clarity half

A writing discipline of any flavor (Lean Canvas, the JTBD canvas, the BBH brief template, Keep a Value's VALUE.md, a one-paragraph readme written before the first commit) does three things on the clarity half:

That is a real intervention. It works.

It does not work on the other half.

Half two: the stopping-power deficit

The stopping-power deficit looks like this. You know the recipient. You have written it down. You have validated it with three real customers in the last month. A calendar invite, Friday at 2pm, to call the fourth, is the move.

It is Thursday at 11:38pm. You are refactoring the email-sending code on a product nobody uses. You can see yourself doing it. You will refactor for another two hours, sleep four, wake up tired, and on Friday at 1:50pm tell yourself you are too tired for a good call. You will reschedule.

This is not a clarity deficit. The recipient is named. The change is named. The way you would know it landed is named. The writing is done. What you have is a stopping-power deficit: the inability to stop doing the thing your discipline tells you not to do, even when you can articulate exactly what you are doing wrong, while you are doing it.

What it looks like in the wild

The pain dossier surfaces this sideways. Builders rarely confess it in clean language. They describe the side-project graveyard. They describe the launch that produced silence and the next launch that produced silence and the next.

After launching 37 different products over the last few years, I've had one go viral and almost all the others struggle to get any traction at all.

AlexBelogubov, Indie Hackers

Then I'd launch. And... three sales.

Veronica Llorca-Smith, Substack

Thirty-seven products is not a single clarity-deficit story. Some of those thirty-seven were misaimed; you cannot ship that many without at least three being so. A subset of them were aimed correctly and built anyway because building was the available activity. The graveyard is the record of a builder whose stopping function did not engage.

The build-in-public version is even more legible:

On a build-in-public platform, you and the other founders are each other's audience. You are almost never each other's market.

Max, Indie Hackers

An audience claps, a market pays, and they almost never sit in the same room.

GregoryScottHenson, commenting on Max's post

Applause is the dopamine that keeps the building going past the point at which any honest reading of the data says "stop and go find a buyer." It is a substitute reinforcer. It is not the reinforcer the system needs, but it is the reinforcer the system gets. You ship for the applause because the applause arrives reliably. The check from a buyer arrives never, or rarely, and on a delay too long for the reward system to associate the work with the reward.

The bewilderment version is KasamiWorks:

still trying to figure out which silence means "not yet" and which means "not ever."

KasamiWorks, Indie Hackers

That sentence sounds like a clarity-deficit problem (no falsifier). It is a stopping-power problem in disguise. The reason silence cannot be interpreted is that there is no pre-declared falsifier. The reason there is no pre-declared falsifier is that the builder did not stop before shipping to write one. The stopping would have produced the falsifier; the absence of stopping produced the bewilderment. You can write a falsifier in fifteen minutes. The fifteen minutes is what is missing.

What stopping-power deficit is not

It is not laziness. The thirty-two-year-old indie builder reading this article works hard, ships more than the average employed engineer, and produces high output. The problem is not effort.

It is not lack of discipline in the colloquial sense. They have tried discipline. They have shipped on a one-product-a-week streak. They have done no-zero-days. They have read Atomic Habits and built habit stacks. The discipline is there; it is pointed in a direction that produces shipping without landing.

It is not lack of skill. They build fast and well. The thing they build is not the thing the recipient needs, and the move that would discover the right thing (talking to the recipient) is harder than the move that already feels good (shipping a refactor).

It is the inability to stop building when stopping is the move.

The gap in the literature

The literature has no clean name for this. The closest attempts are scattered across genres. Pressfield's The War of Art (2002) names "Resistance" and tells you to write through it by force of will, producing a rhetoric, not a discipline. Newport's Deep Work (2016) names the value of focused attention but does not address what happens when focused attention is correctly engaged on the wrong thing. Clear's Atomic Habits (2018) is the strongest popular treatment of habit architecture; its four laws produce a set of environment-design moves, not a six-part gate. The founder-burnout memoirs (Lavingia, Fishkin, Justin Kan) name the cost of not-stopping after the fact. They are descriptions, not preventatives.

The clarity half has decades of writing, several competing schools (Lean Startup, JTBD, Design Sprints, customer-discovery scripts), and at least four widely-used canvases. The stopping-power half has a self-help shelf, a programmer-folk-wisdom shelf, and a memoir shelf, and no equivalent of a six-part gate.

The literature on the second half is thin. It is thin because the phenomenon is hard to study (it requires intervention at the moment of the unwanted building, which is private), hard to write about without becoming motivational (the line between "discipline" and "shame" is small here), and hard to falsify (when does "I should have stopped" become "I should have built more"?). The honest move is to name the gap and stop expecting the clarity-half tools to solve the stopping-power-half problem.

What writing disciplines cannot do

A writing discipline cannot make you call the fourth customer. It can put on your wall the three sentences that say calling the fourth customer is the move. You will read the sentences on Thursday at 11:38pm and refactor the email-sending code anyway.

A writing discipline cannot make you close the editor at 11pm, sit through the silence after a launch instead of starting the next project, or take the calendar invite seriously. The silence is intolerable; the next project is a project; you will start it.

A writing discipline can do this much for the stopping-power half: put the diagnosis on the page so that when you re-read the page, you have a chance, in a calmer moment, to recognize what you are doing. That is real. It is not a cure. It is what a doctor does for a chronic condition the medicine cannot cure: name the condition, note its triggers, give you something to read when you are tempted to deny it.

Back-cataloging your last three projects

The exercise below is uncomfortable. The discomfort is the point. The diagnosis is uncomfortable in proportion to how badly you needed it.

Pick the three most recent projects you shipped that did not land. By "did not land," mean: produced fewer paying customers, fewer recurring users, or fewer recognizable wins than you wanted. Write the project names in a doc. For each one, answer the prompts below. Then assign each project a label.

Prompt 1: name the recipient as you understood it on day one

Not the recipient you would name now. Not the recipient your post-mortem identified. The recipient you would have named if a stranger had stopped you at the moment you opened the editor on day one.

If the answer is a category ("solo founders," "small businesses," "people who use Notion"), the project was a clarity deficit on its first day. Eventually clarifying the recipient does not retroactively repair the first six weeks of work that were aimed at a category.

If the answer is a specific person ("Sara, my friend who runs the small marketing agency in Toronto"), it was not a clarity deficit on day one. Move to the next prompt.

Prompt 2: name the moment you could have stopped

Find the first moment, two to eight weeks in, when the data was telling you something you did not want to hear. The waitlist was empty. The demo got polite-positive feedback and no follow-ups. The free trial converted at 2% when you needed 10%. Three customers said the price was too high and none of them rewrote you a check at a lower price.

Did you stop? Did you act on the signal? Or did you build the next feature?

If you stopped and acted on the signal, the project did not have a stopping-power deficit. (It can still have died from other causes: distribution, timing, market, money. Those are not the two halves this article is about.)

If you built the next feature, the project had a stopping-power deficit. The clarity-deficit framing will not explain what happened, because at the moment you built the next feature, the clarity was sufficient. You knew the signal. You ignored it.

Prompt 3: name the channel through which validation arrived

Where did the people who said the product was promising live? Were they other builders on IndieHackers, X, Hacker News, your Discord? Or were they paying customers in the recipient's actual workspace?

If validation came from other builders, the project had the recipient-versus-where-you-spend-time variant of the clarity deficit. The recipient was named correctly on the landing page; the validation channel produced applause from the wrong room. The build kept going on the strength of the applause.

If validation came from real customers and you kept building anyway, see prompt 2: stopping-power deficit.

Prompt 4: write the label

Next to each project name, write one of three labels:

Read the three labels out loud. Notice which one is the more common diagnosis. That is the half of the build trap you keep returning to.

The reason this exercise is uncomfortable is that two of the projects were not killed by the market or by timing or by the wrong tech choice. They were killed by something you did, repeatedly, while watching yourself do it. "Stopping-power deficit" does not give you a system to blame. It says: the thing that killed it was your inability to stop, and that thing has not been fixed by any of the discipline you have applied in the years since.

If all three labels come up "clarity deficit," the literature has been built for you. Pick a writing discipline. Apply it. Bring a real stranger in to test the three sentences. Do not skip the stranger step; it is what catches the clarity deficit in cases where you have already convinced yourself the recipient is sharp.

If two or three labels come up "stopping-power deficit" or "both," the literature is thin. Stop expecting the writing-discipline tool to solve the stopping-power problem. Start looking at environment-design moves.

What the second-half literature actually offers

The strongest single book on the stopping-power half is Atomic Habits. Its four laws (make it obvious, attractive, easy, satisfying) and their inversions point at concrete moves: make "building" harder when the move is to stop, make "calling the customer" easier and more reinforcing. Close the editor. Put the call on a different computer in a different room. Schedule the call before noon so the day's energy goes to it. The book is best at habit installation; it is weaker at stopping an entrenched anti-habit, which is what most stopping-power deficits have become by the time you notice them.

The strongest move outside the books is environment design. Hire a coach who calls you on the morning of the customer call. Use a co-working space where you cannot ship code. Take a contract job that pays the bills so the indie project is no longer your primary financial dopamine source. Put the laptop in a locked drawer between 9pm and 7am. These work as much as they work; they do not generalize across people.

What none of this contains is a discipline equivalent to the clarity-deficit writing disciplines: a one-page document, a gate, a falsifier, a stranger test. The stopping-power half does not have one. If it existed, it would have shown up in the top Hacker News results in the last five years. It has not.

Stop waiting for it. Apply the environment-design tools that exist while acknowledging they are weaker than the clarity-deficit tools. Stop blaming yourself for not having a stopping-power discipline as effective as your clarity discipline. The asymmetry is in the field, not in you.

Where Keep a Value sits

Keep a Value is the writing discipline the author has built and dogfooded for six months; it addresses the clarity half with a six-part gate, a stranger test, and a one-page contract called a VALUE.md, and its own text names the limit: it solves the clarity-deficit half and does not solve the stopping-power half. This article depends on the distinction being load-bearing, not on Keep a Value being adopted.

If your past projects are mostly clarity deficits, the menu is long: Lean Canvas, the JTBD canvas, the BBH brief template, the IPA single-minded brief, Keep a Value's VALUE.md, a one-paragraph readme before the first commit. Pick one. Apply it. Bring a real stranger in to test the output. The specific discipline matters less than the act of writing and the stranger test.

If your past projects are mostly stopping-power deficits, no writing discipline solves that. Look at the environment-design list above. Pick one or two. Be honest about the limit.

If your past projects are both, the order matters: clarity first. Without clarity, the stopping-power moves point at the wrong target. Once clarity is in place, the stopping-power problem becomes the unmasked, harder problem it was all along.

What to do tomorrow

Three concrete moves. Each addresses a different half. Each is small enough to complete in a week.

Move 1: clarity (60 minutes)

Open a blank document. Write three sentences. Who is the project for, by name, with a sentence of their last frustrating thirty seconds of behavior. What changes for them after the project lands. How a stranger could check whether the change happened, without asking you.

Send the three sentences to one person who is not on the project. Use this message:

Please read these three sentences with no context and answer in your own words: (1) who is this for? (2) what changes for them? (3) how would you know it happened? If you can't answer, say what was unclear.

If they cannot answer, the project has a clarity deficit and you have just confirmed it. Rewrite. Re-send. Get a "yes, I can answer" before any more code ships.

Move 2: stopping power, environment design (30 minutes)

Identify the unwanted-building behavior. Be specific: "I open the editor after 10pm on weeknights and refactor code on a product nobody is using." Make the behavior 20% harder. Move the laptop to a different room. Install an app that blocks the editor between 10pm and 7am. Move customer-call calendar invites to before 11am, when willpower has not yet been depleted.

Track for one week whether the behavior changed. If it did not, the friction was too low. Add more. If it did, you have evidence that environment-design works on you, which is a stronger personal data point than any of the books above can provide.

Move 3: back-catalog (90 minutes)

Run the back-catalog exercise above on your last three projects. Write the labels. Notice the pattern. Decide which half of the build trap you live in. Tell one trusted person what you decided. The act of telling is part of the discipline; it makes the diagnosis harder to walk back.

You will be tempted to start a new project within forty-eight hours of finishing Move 3. Whether you start it, given what the back-cataloging just showed you about the last three, is the test. This article makes no prediction about how you will do. It promises only that from this point on, you will be able to name which half of the build trap you are returning to, in your own words, within sixty seconds, and that you will stop expecting the writing tool to solve the half it cannot solve.

That is the change this article promises.

Natan Dahan writes the Keep a Value discipline at keepavalue.com.

First published 2026-06-29.