Building a company with ADHD

I talk about ADHD and depression publicly. Not as a brand, and not because I have it solved. I would rather be precise than polished, and staying quiet about it would make everything else I say about how I work slightly dishonest.

The equation #

Most productivity advice is built on one assumption: that an hour is an hour. Fill the calendar, protect the blocks, execute.

That assumption does not hold for me, and I do not think it holds for as many people as the advice assumes. Energy is not time. A four-hour block at the wrong point in the day is worth less than forty minutes at the right one, and no amount of discipline converts one into the other.

Once you take that seriously, a lot of standard advice inverts. The calendar stops being the primary artifact. What you are actually scheduling is state, and time is just the axis you happen to draw it on.

What I changed #

I stopped fighting the good hours. When the work is flowing I do not stop for the meeting I scheduled two weeks ago at a moment when I could not know what this Tuesday would feel like. The meeting moves.

I made starting cheaper than finishing. The hardest part is never the middle, it is the first thirty seconds. So the environment is set up so that beginning costs nothing: the shell is configured, the project opens where I left it, the next action is written down in words a tired person can follow.

I write things down obsessively, not because I might forget, but because having it externalised means I can drop it and pick it up without paying the reload cost twice.

I let the bad days be bad. Forcing output on an empty day produces work I throw away tomorrow plus a day of feeling worse. Two costs, no benefit.

The uncomfortable part #

Running a company on this is harder than the tidy version above suggests.

Investors want predictability. Teams want predictability. "I will know on Tuesday whether Tuesday is a good day" is not a project plan, and pretending otherwise would be its own kind of dishonesty.

What actually works is building slack into commitments rather than into intentions. Ship dates with real margin. Systems that survive a bad week without me. Documentation good enough that my absence is an inconvenience and not a stop.

That is just good engineering practice. It happens to also be the accommodation.

Why it became a product #

Kumbatio came out of this. The name is Swahili for embrace, and the core of it is that equation — energy ≠ time — taken seriously enough to design around.

I am aware of the trap. Building the productivity tool instead of doing the work is the oldest procrastination there is, and I am unusually well equipped to fall into it.

The check I use: does this exist because I needed it on a specific bad day I can remember? If yes, build it. If it exists because it would be neat, it goes on the list with everything else that would be neat.