How I Stay Sane Building Products Solo

The advice for staying sane as a solo builder is usually some version of "take breaks, protect your energy, don't burn out." It's not wrong, but it treats sustainability as a mood you manage. After running more than one product on my own — Delivery Sheet and Listemizde — I've come to think the opposite: staying sane solo is a systems problem, not a motivation problem. The reason I'm still standing isn't willpower or a good morning routine. It's that the way I work has boundaries built into it, so I'm not relying on discipline I won't always have. Same disciplines I already write about for running several products at once — they turn out to be what keeps the builder intact, not just the portfolio.

Two ways solo building breaks you

There are two failure modes, and they look like opposites. The first is over-shipping: chasing every new idea, adding every feature, treating a full calendar as proof of progress until you're exhausted and the products are bloated. The second is drift: no focus, ten things half-built, motion without direction. One burns you out; the other quietly demoralizes you. What they share is that solo, there's no one to catch either. A team has a colleague who says "we already have too much in flight." Alone, the only brake is the one you build into the system beforehand — because in the moment, you'll always find a reason.

What actually keeps it sustainable

Three things hold, and none of them are about trying harder.

The first is building narrow. A product with a tight scope is a product I can hold in my head. Widen the scope and every additional thing it does is another thing to maintain, support, and worry about — solo, that load doesn't scale, it just accumulates. Narrow isn't only a product decision; it's a sanity decision. Fewer things to hold is fewer things quietly running in the background of your attention.

The second is a kill habit. Not the dramatic kind — the routine kind. Experiments that aren't earning their attention get stopped on criteria I set in advance, not dragged out of guilt. A dead experiment you keep half-tending is worse than one you end: it drains attention and it sits there as a small standing reproach. Killing it cleanly gives the attention back and closes the loop. The habit is what stops a solo portfolio from becoming a graveyard you're still paying rent on.

The third is a repeatable operating system. Most of what tires you out solo isn't the hard work — it's the decision fatigue of making the same calls from scratch every time. When the process is fixed — same stack, same way of scoping, same filter for what's worth building — you stop reinventing how to work and spend the energy on the part that's actually new. A system removes decisions. Removed decisions are conserved energy.

Boundaries as a system, not willpower

"

The constraints do the work. Narrow scope, no free plan to support forever, saying no to most features — set those once and they hold the line every day, without asking you to be disciplined in a moment when you won't be.

This is the part I'd most want to have understood earlier. Motivation is not a reliable input. It's high some weeks and gone others, and a way of working that depends on it being high will break on the weeks it isn't. So the boundaries can't live in willpower — they have to live in the structure.

Concretely: a narrow scope gives each product a defined edge, so requests outside it are easy no's rather than agonized ones. No free plan means I'm not committing to support an unbounded number of non-paying users forever. Saying no to most features keeps the surface small enough for one person. None of these require me to be strong on any given day. They were decided once, coldly, and now they hold the line on my behalf. That's the whole trick: move the discipline out of the moment and into the design of how you work.

The product isn't a verdict on you

The failure mode that actually breaks solo builders isn't technical. It's conflating your self-worth with a metric. When there's no team, the product's numbers feel like they're about you — and a flat month starts to read as evidence that you're flat. That's the thought that ends people.

So I keep the two things apart, deliberately. "The product isn't working" is a fact about an experiment. "I'm not working" is a different claim, and usually a false one. A product is a bet with a domain and a market and a hundred things outside my control; its result is information, not a judgment. This is exactly why kill criteria get set in advance and coldly — deciding what "not working" looks like before you're emotionally in it is what lets you read a weak result as data instead of taking it personally. The experiment can fail without you failing. Keep that line clean and you can run many experiments over years. Blur it and the first cold month takes you down with the product.

Why writing it down keeps me intact

Building in public turns out to be part of the sustainability system, not just distribution. Writing the decisions down keeps me honest — it's hard to quietly drift or over-ship when you've committed the reasoning to a page someone might read. It keeps me connected, which matters more solo than people admit; the work is otherwise a room with no one in it. And it changes what a quiet stretch is. A month where nothing launches isn't a wasted month if it produced writing that keeps working after it's published — the slow stretches compound into something instead of just draining away.

Docs vs. reality

The indie feed is all launches and revenue screenshots and momentum. That's the docs version, and read enough of it and you'll conclude everyone but you is shipping constantly and thriving. The reality is that most of the actual work is unglamorous: maintenance, support, small fixes, and long stretches where the discipline that matters most is not burning the whole thing down to chase the next shiny idea. Nobody posts the month they held steady and killed a dead experiment and said no to eleven feature requests.

That's the part I'd tell anyone starting: sustainability isn't a motivation problem you solve by wanting it more. It's a systems problem you solve by building the boundaries in — narrow scope, a kill habit, a repeatable process, and a clean line between the product's result and your own worth. Get the system right and you don't have to stay motivated. You just have to keep showing up to a way of working that was already designed to hold.

Part of Building AI Products. See also what I learned building multiple products at once, my product operating system, and my kill criteria for product experiments. The newsletter sends one practical build lesson every two weeks.