Procrastination Through Hard Work

I am a developer. For most of the past month, I used the one thing I am best at to avoid the one thing my company actually needs. Here is the week that made the pattern impossible to ignore, and what I changed once I saw it.

Procrastination through hard work: a week of refactoring with the customer question left unchecked

My company exists to answer a single question right now: will researchers pay to make their work impossible to overlook? Not “is the code clean,” not “does the architecture scale,” not “is the landing page elegant.” Will a stranger, someone I have never met, find this valuable enough to pay for it. That is the whole game for the first six months. Validation, not scale.

Here is what one of those weeks looked like in the commit log. Around 22,000 lines added, 13,000 removed, 90 commits, 37 pull requests. By any engineering measure, a productive week. Then I looked closer. Roughly 70% of that diff was modularization and deleting dead code. Real work. Genuinely useful. And almost entirely beside the point.

Because none of it moved the only number that matters in a validation phase. The home page held visitors for about two minutes and converted zero of them. Stranger signups: zero. Paying customers: still zero. The codebase got measurably better while the question the business is supposed to answer stayed exactly where it started.

Why does a technical founder do this? I think it comes down to feedback and risk.

Code gives you clean, immediate, impersonal feedback. It compiles or it does not. The tests pass or they fail. Nothing about a failing test feels like a judgment of you. A cold email to a researcher you admire is the opposite. You send it into silence, and silence about work you have poured yourself into reads like a verdict. So you open the editor instead. Refactoring is safe. Asking a stranger for money is not.

Engineering also produces beautiful evidence of effort. Commits, green checkmarks, a tidy diff. You end the day able to point at something. Outreach on a slow week produces a sent folder and no replies. One of those feels like progress. Only one of them is, when the question is whether anyone wants the thing.

The first time I caught this, I wrote it down in a weekly review and assumed that would settle it. It did not. I did the same thing the next week, and the week after. Eventually I added a permanent line to every weekly plan: “Engineering-as-avoidance watch.” A standing reminder, because the pull is standing. The trap is not a one-time mistake you correct and move past. It is a default you have to keep choosing against, every single week.

Here is the version of this that actually changed my behavior.

The avoidance can hide the answer. Every week I spend building instead of asking is a week I do not learn whether anyone will pay. And if the answer turns out to be no, I would much rather know now, cheaply, than discover it after another month of immaculate refactoring. A perfect codebase for a product nobody wants is the most expensive possible way to not find out.

So the next week I was not allowed to ship a feature. The deliverable was conversations: a free guide that handed researchers something useful with no signup wall, a handful of sharper cold emails, and three real interviews with people who agreed to talk. If those produced signal, the pattern is behind me. If they produced nothing, then the pattern was never just procrastination. It was the diagnosis. Either way, I found out. That was always the only point.

Last week Loud Camel, a tool that helps researchers get cited and recognized, shipped no new features on purpose. The deliverables were conversations instead: a no-signup guide, a few cold emails, and booked interviews, scheduled in the slot a feature usually takes. The note for PMs and founders: if “talk to strangers” is not given the same weight as a feature on the plan, the safer work wins every time, and you can lose a month to it before you notice.

· When your LLM pipeline silently returns zero: a scan came back clean and that was the bug. The system failed in total silence.

No new posts on the Hebrew blog this week.

If you are a founder before your first dollar of revenue, the work that feels most productive is often the work that protects you from the answer. Go get the answer.