The Real Constraint on a Solo Developer
Not capability, and not time in total. The constraint is that building and distributing compete for the same hours, and building is the one that feels like progress. Most solo products fail with the product finished and nobody aware it exists, which is a scheduling problem before it is a marketing one.
Why the calendar always resolves toward building
Every solo builder I have talked to describes the same week. There was a plan to post something, or email ten people, or write the launch note. Then a bug appeared, or a refactor became obviously necessary, and the week went to the code.
That is not a discipline failure and I would stop framing it as one. It is an entirely rational response to how the two activities feel.
Building has a tight feedback loop, produces visible artefacts, and is something you are demonstrably good at. Distribution has a slow, noisy feedback loop, produces nothing you can point at on most days, and involves being ignored in public by people whose attention you wanted.
Given a free choice between those every morning, anyone rational picks the code. Which means the answer cannot be resolve harder. It has to be removing the choice.
The version that works for me is boring: distribution gets fixed hours on the calendar, treated exactly like a meeting with someone else, and it happens before the building rather than after. Not because mornings are magic, but because whatever comes second gets eaten by whatever comes first.
The other half is defining distribution work concretely enough that it can be done in a scheduled slot. "Do marketing" is not a task and will not survive the calendar. "Write the section of the docs that answers the question three people asked me this week" is a task, and it happens to also be distribution.
The problems that actually bite
No one tells you your priorities are wrong. On a team, someone eventually says the thing you have spent three weeks on does not matter. Alone, nothing interrupts a bad decision, and you can spend a month on a feature nobody asked for with no signal at all until launch. The only reliable fix is external contact: users, other builders, anyone who will tell you the truth about what you are working on.
Decision fatigue on decisions that do not matter. You are choosing the stack, the pricing, the colours, the copy, the support process, and the invoice template. Most of these have no wrong answer that is meaningfully worse than the alternative. Deciding fast and badly on the small ones preserves the capacity you need for the few that actually compound.
Every outage is yours. There is no rotation, and there is no separation between shipping something risky and being the person woken up by it. This changes what you should build, toward boring and recoverable, more than most solo builders admit.
The non-code work waits for you. Incorporation, contracts with the first real customer, terms, tax treatment, how you handle a refund. None of it is urgent until it very suddenly is, usually at the moment something good happens. I would spend an hour getting the structure right early rather than unpicking it during a deal, and this is general information rather than legal advice, so get the specifics from someone qualified in your jurisdiction.
Isolation degrades judgement. Not morale, judgement. Without anyone to argue with, ideas do not get stress tested and you slowly lose calibration on what is obvious to a reader versus obvious only to you.
Working in public is the highest leverage habit available
It solves several of these at once. It forces regular external contact, which corrects priorities. It produces distribution as a byproduct of work you were doing anyway. And it creates a record of your thinking that becomes the thing people trust before they trust the product. The cost is discomfort, mostly at the start, and I think it is the cheapest exchange available to a solo builder.
What I would actually do
Concretely, if I were starting alone tomorrow.
Define one distribution task per working day, small enough to finish in an hour, specific enough that you cannot negotiate with it. Ship it before touching the code.
Talk to a real user every week without exception, even when the product is unfinished and especially when you do not want to. This is the mechanism that replaces the colleague who would have told you your priorities were wrong.
Write in public about the actual problem you are solving, not about your progress. Progress updates interest people who already care. Problem writing reaches people who have the problem.
Make the small decisions in minutes and write down why, so you stop revisiting them.
And handle the structural work early, in one deliberate pass, so that it is done before it becomes an emergency at the worst possible moment.
None of this is clever. The advantage of working alone is speed and the absence of coordination cost, and both are wasted if the entire output is a product nobody has heard of.
Frequently asked questions
- What is the hardest part of being a solo developer?
- That building and distribution compete for the same hours, and building is the one that feels like progress. Building has a tight feedback loop and visible output. Distribution has a slow, noisy loop and involves being ignored in public, so the calendar quietly resolves toward code every time.
- How do you make yourself do marketing when you would rather build?
- Remove the choice rather than trying to resolve harder. Give distribution fixed calendar hours before the building rather than after, and define the work concretely enough to complete in one slot. Do marketing is not a task and will not survive; writing the docs section three people asked about is.
- What replaces having colleagues?
- Deliberate external contact, because nothing else interrupts a bad decision when you work alone. Talk to a real user weekly regardless of how unfinished the product is. The value is not feature requests, it is the correction to priorities that a colleague would otherwise have given you for free.
- What non-code work do solo builders defer too long?
- Incorporation, customer contracts, terms, tax treatment, and refund handling. None of it is urgent until it suddenly is, usually at the moment something good happens and you are unpicking it during a deal. Handle it early in one deliberate pass, with advice from someone qualified in your jurisdiction.