← Writing

Why you keep planning and never building

Because a plan is the only part of building that can't tell you no. I built a product to stop me doing it and it still caught me twice.

· 2026-09-03 · 6 min read


I spent five days of a hackathon running myself through my own product. The record at the end says LAUNCH, seven proofs banked, six of them from actually talking to people. It also says the gate refused me on two of those five days, and the refusals are the only part of that run I learned anything from.

On both of those evenings I had worked. I would have told you I had worked and I would have meant it. What I did not have was anything I could file.

A plan is the only part of building that can't tell you no

Message a stranger and they can leave you on read. Put the thing in front of someone and they can look at it politely and change the subject. Post it and the post can just sit there. A document has none of that. It gets better every time you open it and it has never once told me the idea was thin.

So the pull toward planning isn't laziness, which is the thing I had wrong about it for a long time. It's a preference for the one activity with no downside, and it gets stronger the more you care about the idea. The builders I know who plan longest are the ones most invested. Telling them to try harder does nothing, because effort was never the missing input.

There's a duller reason it sticks, too. Planning produces evidence of itself. Four hours in a doc leaves you with more doc than you started with, and whatever gauge you use for your own progress reads positive. Four hours of outreach can leave you with three unanswered messages and one person who said, kindly, that the problem doesn't really bother them. The second afternoon was the useful one, and there is nothing inside your own head that will tell you so.

The deadline you set is the deadline you move

The standard answer to all this is a date. Ship by the 14th. Mine slipped so reliably that at some point I stopped writing them down.

It isn't a willpower problem. When the 14th arrives and the thing isn't ready, the person who decides whether that counts is the person who set the date, and he has good reasons. The scope changed. The week was bad. It's nearly done. Any one of those can be perfectly true, which is exactly what makes them work.

Accountability partners do better, because the referee is somebody else. They also decay, and I think the reason is more specific than people usually say: your friend doesn't want to be the one who tells you your evidence was thin. Give it a month and the weekly check-in has softened into a conversation about how it's going, which is planning with a witness.

What held was a bar that couldn't hear me

What eventually worked on me is unglamorous and mechanical. A specific bar, set before I started, checked against what I had filed rather than what I said about my week, with no capacity to be talked round.

That's all Masterji is. It isn't a coach in the sense of someone with insight into your market. It makes no claim to founder wisdom and I'd be suspicious of anything that did — I haven't built something thousands of people use. What it has instead is a gate.

You commit to one goal. Each morning you declare one task. Each evening you file proof that you did it, and an evening with no proof doesn't count. Phases open on accepted evidence and not on your say-so: IDEA wants one written problem statement and who has the problem, VALIDATION wants three conversations with three different people, BUILD wants a working thing plus evidence a real person touched it.

The part that does the work is where the check lives. It's a database query, not a paragraph of instructions to a model. The model can propose that you advance; the server counts the rows and refuses if they aren't there. No sentence you write changes what a WHERE clause returns. During that hackathon the phases were ones I could not have skipped without editing my own database, and knowing that is what made the two refusals land.

The hiding place I didn't design for

A builder who wasn't me used it for an evening. He hit a refusal, and then spent the rest of the evening arguing with the coach about whether the refusal was fair.

The gate held. It was right to refuse him and it didn't budge. He still lost the evening, and he lost it to something that felt like working on his startup. Masterji promises no hiding in planning; this was a third hiding place, and because I had deliberately decided the coach should never cap how much you can push back, arguing was free and unbounded by design.

A refusal that engages is a refusal that rewards the arguing.

My first instinct was a cap: after so many refusals, accept the next thing. That is a terrible idea and I am glad I wrote it down before building it — it hands a proof to anyone willing to paste four times, and the gate is the entire product.

The reason a count cannot decide is the part worth keeping. Two completely different failures produce an identical stack of push-backs: the work isn't there, or the work is there and the two of you cannot understand each other. From a refusal count those look the same, only the first is the builder's fault, and the second is what my user hit.

So the count does not get to decide — it forces a question. Past three refusals the coach has to stop and answer which of the two is happening, and then it still judges. Refusing on the fourth try stays available and is right about half the time it comes up.

What is still missing is the thing that would actually have saved that evening: past some point the coach should stop negotiating and end the day. Nothing would pass that wouldn't have passed before; the conversation simply stops being somewhere an evening can go. That part is not built.

Four rules, if you'd rather not trust a product

None of this needs software. The mechanism fits in four rules and you can run it out of a notebook tomorrow:

  • One goal. One sentence, and no second sentence.
  • One task, declared in the morning, before the day can be reinterpreted by how it went.
  • Proof in the evening, or the day didn't count. Proof is something outside your own head: a reply, a screenshot, a link somebody opened. Not an account of what you did.
  • The bar for the next stage, written down before you're near it, and handed to somebody who doesn't mind disappointing you.

People skip the fourth one, and the fourth one is the whole thing. A bar you can still edit when you reach it is a bar that gets edited when you reach it.

India has more people who want to start something than almost anywhere. The GUESSS survey put 32.5% of Indian college students at the nascent-entrepreneur stage against 25.7% globally, and roughly 4.8% of student ventures ever make revenue. I don't think what sits in that gap is knowledge. Nearly everyone in it could find out what to do next in an afternoon, and a lot of them will spend the afternoon finding out.

Masterji is free and there's a walk-through that needs no sign-in, if you want to see what a refusal actually looks like before you point one at yourself.