One person built this

Everything on this site was built by one person, which sounds like a boast and is mostly a constraint. Here is what the constraint actually does to the work.

You cannot hide behind a roadmap

With a team, a bad idea survives because moving it out of the plan costs a meeting. Alone, a bad idea survives until the exact moment you have to build it, and then it dies immediately, because you are the one who has to do it.

That sounds like an advantage, and half of it is. The other half is that this filter only catches ideas that are painful to build. A bad idea that takes twenty minutes will sit in the codebase for two years, because nothing in the process ever asks whether it should be there. Nobody opens a PR and says “wait, why?” The friction is doing the honest work of judgment, and friction is a terrible proxy for correctness.

So the roadmap doesn’t protect you from bad ideas. It protects you from expensive bad ideas. The cheap ones accumulate quietly.

The cost is not code

It is context.

Five projects means five sets of decisions you have to reload every time you sit down. The tax is not typing, it is remembering why you did it that way in March.

You open something you haven’t touched in six weeks and there is a function doing something obviously stupid. The question is never “is this stupid.” The question is “was I stupid, or was I working around something.” Those look identical from the outside. Answering it means rebuilding the entire mental model that produced the decision, and that model is gone. You are now an archaeologist studying yourself.

Sometimes you rebuild it and the reason was real. Sometimes you rebuild it and there was no reason. Either way you paid the same price to find out.

The compounding version of this is worse. Every project you keep alive is a standing subscription. Not to maintenance, to recall. You are not paying for the code, you are paying to still be the person who understands it.

No one is going to tell you it’s wrong

The review process is you, later, in a worse mood.

This cuts both ways and people usually only mention the good direction. Yes, you ship without waiting for anyone. You also ship without anyone noticing the thing you didn’t think of, and there is a specific category of mistake that survives solo work indefinitely: the mistake that is internally consistent. If your reasoning is coherent and your premise is wrong, nothing in your own head is going to catch it. You will build a very tidy structure on top of a bad assumption and feel productive the entire time.

Users catch some of this. Users catch it late, and they mostly don’t tell you, they just leave.

Momentum is the resource, not time

Everyone talks about time as the scarce thing. It isn’t, or at least it isn’t the binding constraint. The binding constraint is the state of having a project loaded in your head.

Getting there takes real effort. Losing it takes an interruption. And the recovery is not proportional to the length of the break, it is proportional to how deep you were. A twenty-minute interruption during shallow work costs twenty minutes. The same interruption during the part where you finally understood the whole shape of the problem can cost the afternoon.

This is why “I’ll just switch to the other project for a bit” is the most expensive sentence in solo development. You are not switching tasks, you are unloading and reloading a machine.

Finishing is a different skill from building

The last ten percent has no interesting problems left in it. Error states, empty states, the settings page nobody asked for, the copy on the confirmation dialog. None of it teaches you anything. All of it is the difference between a project and a thing people can use.

Alone, there is nobody whose job it is to care about that part. There is no deadline external to you, no one waiting. So it doesn’t happen, and you end up with a folder of things that are ninety percent done, which is a folder of things that are zero percent done.

The graveyard is not made of hard problems. It is made of boring ones.

What I do about it

I write things down here.

That’s the honest answer and it is smaller than the problem. Writing a decision down does not preserve the model that produced it. It preserves a sentence about the model. When I come back six weeks later I get the conclusion without the reasoning, and half the time the conclusion alone is not enough to reconstruct whether it still applies.

What it does do is narrow the search. Instead of “why is this like this,” I get “here is what I was worried about in March,” and I can go check whether I am still worried about it. That is a smaller question and I can usually answer it in an hour instead of a day.

It is not a system. It is a set of notes that fail slightly less often than having no notes.

That is roughly what all of this is like.