Shipping a product alone: the system I actually use

For a long time I thought the hard part of building a product on the side was the building. It isn't. The building is the part I'm good at and the part I enjoy. The hard part is that the product has to survive forty-plus hours a week of something else, and it has to survive the weeks where I have nothing left.

I lead a small tech team building B2B software. That's the day job, and it is a real job — people depend on my attention during it. BiBoTracking, my employee time tracking product, gets whatever is left. For the first year I treated "whatever is left" as a motivation problem. I'd tell myself I'd work on it after dinner, and some nights I did, and most nights I opened the repo, read some code, changed nothing, and closed the laptop feeling behind.

What fixed it wasn't discipline. It was shrinking the decision surface until almost nothing was left to decide.

The week has three slots, not seven

The version of my week that actually works has exactly three slots for the product. Not "evenings." Three named slots.

Sunday morning, about an hour: decide. I pick one thing. Not a sprint, not a list — one thing that could plausibly be done and shipped by the following weekend. I write it down in the repo, in plain language, as a sentence that describes what a user would be able to do that they couldn't before. If I can't write that sentence, the thing isn't ready to be worked on and I pick something else.

Two weeknights: build. Fixed nights, not "two nights sometime." Fixed, because a floating night is a night I negotiate with myself about, and I lose that negotiation. Each session starts by reading the sentence I wrote on Sunday. No triage, no inbox, no "quick look at the logs first." The logs are a trap that eats a whole session and produces nothing.

One hour on Saturday: ship or don't. Deploy, check it, write down what happened. If it isn't ready, it doesn't ship, and I don't extend the hour. That last part took me the longest to learn.

Three slots is roughly five hours a week. It sounds pathetic written down. It is also, by a wide margin, more than I was getting from the version of me who was theoretically available every night.

The Sunday hour is the whole system

If I had to throw away two of the three slots, I'd keep Sunday.

Deciding is the expensive part, and it's expensive in a way that doesn't look like work. When I sat down on a Tuesday night without having decided anything, I'd spend the first thirty minutes reconstructing context — what was half-finished, what I'd meant to do, whether that bug in the sync path was still a bug. By the time I knew what to do, I had twenty minutes and no appetite for starting. Then I'd pick something small and safe instead, like a copy change, and call it progress.

Doing that deliberation once, cold, on a Sunday, with coffee and no code open, changed the economics completely. I'm making one decision a week instead of ten, and I'm making it when I'm rested rather than at 10pm when the cheapest option always wins.

It also forced a thing I'd avoided: writing the decision down somewhere my future self would actually read. I keep it in the repo, next to the code, in a file I touch every session. Not a tracker, not a board. A board is a place where ideas go to accumulate and quietly shame you. A single sentence is a commitment.

Scope gets cut on Sunday or it gets cut on Saturday

The sentence I write on Sunday is almost always too big the first time. I've learned to cut it before I start, not after. "Let a manager see a team's week" becomes "let a manager see one person's week." The smaller version ships. The bigger one sits half-built across three weekends and then I come back to it having forgotten why I'd structured it that way.

The honest version of this: solo, there is nobody to negotiate scope with. No PM pushing back, no designer asking what happens in the empty state. So I have to be both people, and the only time I can reliably be the sceptical one is when I'm not also the one with my hands in the code.

The weeks nothing shipped

This is the part that usually gets left out, so: plenty of weeks, nothing shipped.

Release weeks at the day job, mostly. When work is in a crunch, the side product gets nothing — not a reduced version, nothing. There were also stretches where I was just tired, and a couple where I was in the middle of something genuinely hard and three weeks of slots produced one working change.

For a long time a dead week would cost me two or three more, because I'd come back feeling like I owed the product something. I'd try to make up the deficit, overreach, break something, and then avoid the repo for another week.

What helped was deciding in advance that a zero week is a legal outcome. On the Sunday after a dead week I don't look at what I missed. I pick one thing, same as always, and I deliberately pick something small — something I'm sure I can finish — because the thing I need back is the habit, not the velocity.

The other half of that: the system has to survive being ignored. That means the product has to be boring to run. One binary, a database I understand, deploys that are one command and that I've rolled back before. Every piece of cleverness in the infrastructure is a thing that will break during a month when I'm not looking at it, and I'll have to re-learn it from scratch to fix it. I wrote more about how that preference came out of actually running the thing in Building BiBoTracking: what one product taught me.

Writing down what shipped, out loud

The last piece is public, and it's the one I resisted.

Once a month I write what actually shipped — publicly, by name. The most recent one is What I shipped in October 2026. It's not marketing; almost nobody reads it the week it goes up. It's an audit I can't fudge. Monthly is slow enough to be honest and fast enough that I can still remember the details.

What the monthly log taught me is that my sense of a month is unreliable in both directions. Months that felt wasted turn out to have three real changes in them. Months that felt productive turn out to be refactors, config, and me re-reading my own code. The log is the only reason I know which is which.

What I'd do differently

Two things.

I'd start the Sunday hour much earlier. I spent close to a year treating the problem as "not enough time" when it was "too many decisions made at the worst possible moment." Those feel identical from the inside and they have completely different fixes.

And I'd cap it harder. The Saturday hour has a hard edge now, but it got there by me blowing past it repeatedly, shipping tired, and spending the next week undoing it. A deploy made at midnight because I didn't want to admit the week was over has never once been my best work.

Five hours a week, one decision, one audit a month. Not a system I'd put in a talk. But the product is still alive, still shipping, and I still have the day job — and for a side project, surviving is most of the result.