Shipping a platform solo, or what a year of moving deadlines looks like

A year of building D3Designs solo, and the thing nobody warns you about is that the deadlines move.

Not in the way deadlines move at a regular job, where someone slips a date by a sprint and there is a meeting about it. They move because there is nobody to hold them in place except you, and you are also the person doing the work, and the work is always more than you estimated, and the only person you are accountable to for the slip is yourself, who already knows you are doing your best.

The honest version of solo work is that the calendar is a suggestion. The thing you said you would ship by the end of the month is now shipping when it is ready, which is whenever it is ready, which is later than you said.

The 1% a day compounding cliché

There is a cliché that says 1% better every day is 37x better in a year, or 365% better, or whatever the math is. It is the kind of line that gets reposted on LinkedIn under a sunset photo.

I think it is mostly true. I also think it is the kind of true that is annoying to hear out loud.

The version of it that actually applies to building a platform solo is that the work compounds even when the calendar says nothing visible happened this week. The schema you wrote three months ago is still doing its job. The pipeline you cleaned up in June is still composing. The docs you wrote when you could not face the codebase are still where you go when you need to remember what you were thinking. None of that is in any particular week's commits. All of it is in the product.

The compounding is real. The frustration is also real. Both are true at the same time, which is the part the LinkedIn post does not acknowledge.

The actual failure mode is feature hell

The thing that keeps almost breaking the solo model is not deadlines. It is the urge to split off into feature hell.

Every week there is a new idea that sounds great. A new entity type. A new editor mode. A new export format. A new integration. The product is large enough now that I can keep myself busy for months adding things that nobody asked for, and the dopamine of a new feature is much higher than the dopamine of fixing the boring thing that needs to be fixed before the next feature can land.

The discipline is in saying no to my own ideas more often than I say no to anyone else's. I am not great at it. The roadmap I told myself I was working on six months ago is not the roadmap I actually worked on, because somewhere in the middle I built three things that were not on it. Some of those three things were good calls. Some were not. The honest accounting is that I do not always know which were which until much later.

What I now know more about than I wanted to

Specific to this product: I have learned more about the D&D 5e SRD than I will ever need to know.

I can tell you off the top of my head which classes are spellcasters, which subclasses change the spellcasting ability, how proficiency bonus scales by level, what counts as a martial weapon, what a legendary action does, why the rules for grappling are the way they are, and what the actual difference is between a creature's challenge rating and its expected damage per round. None of this was in my head a year ago.

That is what building a domain product does to you. You think you are building software, and you are, but you are also absorbing the domain by force. The schema makes you. The prompts make you. The bug reports from real DMs make you. By the end of the first year, you are no longer just a developer who happens to be building a D&D tool. You are a developer who has accidentally become a sort of D&D nerd, and you are fine with it, and you might even be enjoying it.

What I tell myself

Deadlines move. Features multiply. Domain knowledge accumulates in places you did not expect it to land. Most of what you do this week is not what you said you would do at the start of it.

The work compounds anyway.

That is the trade. I think it is mostly worth it.