Shipping a product alone: the system I actually use

I lead a small tech team during the day. At night and on weekends I build BiBoTracking, an employee time tracking product, plus the smaller tools that grew out of it. Nobody assigns me tickets on the side projects. Nobody notices when I skip a week.

That last part is the whole problem. Shipping a side project solo isn't hard because the work is hard. It's hard because there is no external pressure, so the only thing holding it together is a rhythm you invented and have to keep believing in.

What follows is the system I actually use, not the one I'd describe if I were trying to look organised. It has gaps in it. Some weeks it produces nothing.

The system is a week, not a day

My first attempt at this was a daily habit. One hour every evening on the product. It lasted a couple of weeks and then collapsed, and it collapsed in a specific way worth naming: I'd sit down at 10pm, spend most of the hour reloading where I'd left off, make one small change, and go to bed. The next night I'd reload again. I was paying the startup cost every single day and almost never getting to the part where you have enough context in your head to make a real decision.

So I moved the unit of work from a day to a week.

Now a week has one thing in it. Not one task — one thing that ships. A week might be "the invite flow actually sends an email and the email actually works." It might be "the activity list stops being unusably slow." It is deliberately bigger than a ticket and deliberately smaller than a feature.

The weekday evenings stopped being build time. They became thinking and prep time: read an error log, write down the three cases I hadn't considered, sketch the schema change on paper, delete the idea I'd had on Monday that wouldn't survive Thursday. Then the actual building happens in one or two long blocks on the weekend, where I have four or five uninterrupted hours and the context stays loaded.

The honest cost of this: the product moves about four times slower than it feels like it should. I've made peace with that. What I haven't made peace with is how long it took me to admit it — I spent months treating my evening hour as if it were real build time and then wondering why the roadmap never moved.

What goes in the week, and who decides

The hardest part of building alone isn't the engineering. It's that you are also the product manager, and the product manager has no boss and no users in the room.

I use three rules to pick the week's one thing.

Anything a real user hit beats anything I imagined

If someone using BiBoTracking ran into it, it goes to the front of the queue, even if it's small and boring. The reason is simple: it's the only input I have that isn't my own opinion. Every other item in the backlog is me guessing. I wrote more about how much that guessing costs in Building BiBoTracking: what one product taught me — the short version is that most of what I built on instinct, nobody needed.

If it isn't visible to a user, it needs a reason I can say out loud

I love infrastructure work. Deployment scripts, monitoring, cleaning up the data layer. It feels like progress and it's comfortable, because no one can tell you your refactor was the wrong idea. So I made the test explicit: if the week's thing isn't user-visible, I have to be able to say in one sentence what it unblocks. "The deploy is manual and I'm scared of it, so I don't ship" is a good reason. "The models are a bit ugly" is not.

I don't let AI pick the week

I use AI heavily in the actual building — scaffolding, boilerplate, the tedious parts, first drafts of things. That's been a genuine multiplier on the hours I have.

Where it went badly was when I let it tell me what to build. I asked it for strategy, it gave me something that sounded like strategy, and I spent real weekends on it. The output was confident, well-structured, and about a product that didn't exist. That one has its own post: "Vision" or "Hallucination"? — Hard Lessons from Delegating Product Strategy to AI. The rule I keep now is narrow: AI does the work inside the week, I decide what the week is.

The weeks nothing ships

This is the part most "my solo workflow" posts leave out, and it's the part that actually determines whether you're still doing this in a year.

Some weeks nothing ships. There are three kinds, and they aren't the same.

Day-job weeks. A release, an incident, a team member needing a lot of my attention. The day job pays for everything and comes first. These weeks I don't try to force a build block. I do the cheapest useful thing instead — reply to a user, fix one typo in the app, write down one decision — so the product doesn't go completely cold in my head.

Weeks I underestimated. I picked a thing that looked like one weekend and was actually three. Half-finished, not shippable, no visible progress. These used to make me feel like I'd wasted the time. Now I write down what the remaining work actually is before I close the laptop, because the real waste isn't the unfinished work — it's losing the map and having to rebuild it from scratch next Saturday.

Flat weeks. No excuse. I just didn't want to. I opened the editor, looked at it, and went and did something else. For a long time I treated these as a discipline failure and tried to push through, and pushing through produced some of my worst decisions — rushed schema changes I later had to undo, features bolted on because I wanted to feel productive.

What I do now is stop pretending. I skip the week properly instead of half-working through it, and I don't let a skipped week turn into a skipped month. The rule is: one week off is rest, two in a row means something is wrong with the thing I picked, not with me. Usually the thing was too big, or I secretly didn't believe it mattered. Both are fixable by choosing differently, not by trying harder.

The reason I'm specific about these three is that they need different responses. For years I had one response — guilt — and guilt is useless because it doesn't tell you which problem you have.

What I'd actually change

Two things.

I'd make shipping cheaper much earlier. For a long time my deploy was a thing I had to concentrate to do, which meant I batched changes up, which meant every release was large and slightly frightening, which meant I released less often. I eventually got it to one script I can run without thinking. That single change did more for my output than any productivity system I tried, and I should have done it in month one instead of month whatever-it-was.

And I'd write down the week's one thing somewhere I'd see it. It sounds trivial. But the failure mode of working alone isn't laziness — it's drift. You sit down on Saturday with four good hours and no decision made, and you spend the first hour deciding, and you pick whatever is most interesting rather than whatever matters. Writing the sentence down on Tuesday costs nothing and removes that entire failure.

That's the system. One thing a week, picked from real user signal, built in long weekend blocks, with the explicit acceptance that some weeks produce nothing and that's survivable. It isn't impressive and it isn't fast. But it's still running, which is more than I can say for every clever version of it I tried first. If you want the concrete output of a month of this, I write it up as I go — What I shipped in October 2026 is the most recent one.