Why I build alone

Twenty hours a week, one person, several products. That is the outline of how I build right now. I am not trying to argue against teams. I just want to write down how those three numbers end up deciding the shape of everything.

The real constraint is attention, not time

Alongside a day job, what I can honestly set aside is twenty hours a week. What is scarce is not money or skill — it is attention. The moment you fix the number at twenty hours, almost every design decision follows from it in a chain.

Attention shrinks when you split it. Keeping two things alive returns more, out of the same twenty hours, than nudging ten things forward a little. So I do not spread out. Right now it is only Sonir and jpzip. Every "I could also do that" thins the attention until nothing is finished properly. That is something I learned by walking into it more than once.

Choosing not to run a server

jpzip is just static JSON served from a CDN. Sonir does its measurement entirely on the device. Neither needs a server tended around the clock. This is less ideology than arithmetic for surviving on twenty hours.

A server that needs care is a tax levied on every future week. It pages you when it falls over, asks for tuning when it gets busy, and rots if you leave it alone. A server you stand up once keeps shaving a little off every week thereafter — not building time, but keeping-it-alive time. I reach for Local First and static delivery not to look a certain way, but because a design that does not steal attention to maintain is the only kind that fits inside twenty hours.

When I build, the question I dwell on longest is this one: will it keep running without me? If the answer is "no, it needs me," I go back and reconsider the design.

Building alone is about avoiding coordination

I will not dress up solo work as a lonely aesthetic. It is a judgment about coordination cost.

On a budget of twenty hours, working with someone means reconciliation and syncing eat into the budget. Zero meetings, zero hand-offs, zero consensus-building. Everything that frees up goes back into making. The meaning of being alone is not the solitude — it is that all twenty hours convert straight into moving hands.

To be honest, it is slow

It is not all upside. One person is simply slow. Sonir has sat in its testing phase for a long while. I cannot parallelize myself, so moving one thing forward stops the other. Some things ended without ever shipping. Support, marketing, and judgment are all carried here, alone.

I keep at it anyway because I get to hold the whole line — the code, the design, the domain, the license. Ship code first; let the design earn its place by subtraction; grow things that last. That single throughline runs through, with no one else trimming it. A jpzip kept in tune every month and alive for years is worth more to me than ten launches, I have come to feel. Compounding only pays out to whoever stayed.

The unglamorous habits that keep it going

What I hold to, for the sake of lasting, are not flashy routines. Just three.

One: choose designs that run without me — static delivery, Local First, no on-call. These give time back. Two: do not grow the number of products. Two, kept for a long time, is the ceiling. Three: write things down. Future-me does not remember today's context. Leave the reasons behind a decision in writing, and even two weeks later you can resume from where it stopped.

The shape of solo development was never about spinning the wheel fast by force of will. Hold a few things, choose designs that do not generate trouble, and at a speed you can keep, simply do not stop. Twenty hours, as long as I keep to that, is a speed I feel I can sustain.

Common questions

Isn't it lonely? Not while I am building. With no coordination, it is quiet, if anything. The hard parts are carrying support alone, and having no one to talk a decision over with. I patch that, a little, by writing things down.

Why not raise money or hire? Both make you faster, but neither makes attention faster. Hiring brings coordination back; funding brings responsibility for growth back. Either one breaks the twenty-hour premise. For now I choose the speed that keeps it intact.

How do you decide what to build? First I look at whether it will steal attention to maintain. Anything that holds a server around the clock, or needs daily minding, will not last on twenty hours. Whether I will keep using it myself matters just as much — the things I do not use are the things whose upkeep quietly stops.

Twenty hours a week — does it really last? It does not move fast; I will grant that. But whether it lasts is decided by design, not speed. As long as I hold a small number of things that need no tending, twenty hours has been an amount I can pay for years.