The blocker list: what actually stalls solo builders
It is almost never the hard technical problem. Weeks disappear into decisions that were never worth making, and into work that could have waited a year.

The short version
- The visible blocker is rarely the expensive one — weeks disappear into reversible decisions and premature work.
- If you can undo it in a day, decide it in an hour. Framework and folder-structure debates are almost all reversible.
- Build for ten times your current load, not a thousand; automate on the third repetition, not the first.
- There is usually exactly one uncomfortable task being avoided, and it is the highest-information one available.
Ask a stalled founder what is blocking them and you will usually hear something concrete — an integration, a bug, a design decision. Watch the same founder's week and the real answer is different. The time goes somewhere else entirely, and it goes there quietly.
Decisions with no reversal cost
Framework, hosting, ORM, folder structure, whether to use a monorepo. These feel foundational, which is why they attract days of research. Almost all of them are reversible in an afternoon at your current size. The rule that saves the most time: if you can undo it in a day, decide it in an hour.
Work that assumes success you do not have yet
Multi-tenancy before the second customer. An admin dashboard before there is anything to administer. A design system for six pages. Rate limiting for traffic that has never arrived. Each is legitimate engineering, and each is a bet that you will need it before you need users. That bet has bad odds.
- Build for ten times your current load, not a thousand — the rewrite at ten times is cheap and informed.
- Automate a task the third time you do it, not the first.
- Every internal tool is a product you now maintain. Charge yourself accordingly.
The unfinished thing you are avoiding
There is usually exactly one: the pricing page, the cold email, the demo recording, the conversation with a user who might say no. It is the highest-information task available and it is the one that gets rescheduled. Everything else on the list is, functionally, a way of not doing it.
If your week produced no evidence about whether anyone wants this, it was a hobby week. That is allowed occasionally — but it should be a choice, not a surprise.
Put this article to work
Ask it a question, or turn it into a to-do list for your own project. Both answer strictly from this article — nothing invented.
Answers are generated from this article only and are a working draft, not advice.
Questions this answers
Why do solo founders get stuck?
Rarely on the hard technical problem. Time goes into decisions that are reversible in an afternoon, into engineering for a scale that has not arrived, and into avoiding the single uncomfortable task — the pricing page, the cold email, the user conversation that might end in no.
How much should you plan for scale before launch?
Roughly ten times your current load. A rewrite at ten times is cheap and informed by real usage; work done for a thousand times is a bet that you will need capacity before you need customers, and that bet has poor odds.
How do you know if a week was productive?
Ask what you learned that you did not know on Monday. A week that produced no evidence about whether anyone wants the product was a hobby week — acceptable occasionally, but it should be a choice rather than a surprise. Two blank weeks in a row is a scope problem, not a motivation problem.
Building something?
Put it in front of founders who read this — free listing, community-voted, reviewed before it goes live.


