How I Avoid Burnout Running Six Apps Alone (Spoiler: I Don't, Always)
The honest version of solo-founder sustainability isn't a clean system with perfect boundaries. It's a messier equilibrium that breaks sometimes, and what I've actually learned from the times it did.
Every version of this post I've seen from other solo founders reads like a productivity system that works. Time-block this, batch that, protect your mornings, never work weekends. I've tried versions of all of it. Some of it helps. None of it means I don't still burn out sometimes running six live products by myself. Here's the honest version instead of the tidy one.
The System That Mostly Works
I do have real structure, and it's not nothing. Each product gets a defined slice of the week instead of getting attention purely based on which one's on fire. Support and bug triage happen in one sitting rather than getting checked constantly throughout the day, because constant checking is its own kind of exhausting even when nothing's actually wrong. And I genuinely do protect the first two hours of most mornings for the thing that needs the deepest focus, before anything else gets a chance to fragment my attention.
That structure is real and it does most of the work most weeks. This isn't a post arguing structure doesn't matter. It's a post about what happens on the weeks it isn't enough.
Where It Actually Breaks
When two products need me at the same time. The whole system assumes I can mostly attend to one thing at a time and let the others idle safely. That assumption fails when a production issue in one product lands the same week a launch deadline hits in another. There's no time-blocking trick that creates more hours. What actually happens is I pick one, the other one waits, and I feel behind on it for days after — even once it's handled.
When the tired isn't about hours worked. The exhausting weeks aren't always the weeks with the most hours logged. Sometimes it's a week with a reasonable schedule that's still draining because every single task required a context switch between a completely different codebase, a completely different user base, and a completely different set of concerns. Six products isn't six times the work of one product. It's six times the context-switching cost layered on top of the actual work.
When I don't notice until after. The honest failure mode isn't "I saw burnout coming and pushed through anyway." It's that I usually don't notice I've been running too hot until a few days after it's already cost me something — a sloppy decision, a short reply to a user that I regret, a week where nothing shipped even though I was "working" the whole time. The system doesn't have a real-time warning light. It has a pattern I recognize in hindsight.
What Actually Helps When It Breaks
Not a better system. Actually stopping. The instinct when a week goes sideways is to push through it and catch up on rest later, and that instinct is wrong every time I've followed it — "later" doesn't reliably arrive, and the debt compounds instead of clearing. What's worked, on the rare occasions I've actually done it, is stopping for a day or two the moment I notice the pattern, rather than after it's gotten worse.
The other thing that helps is genuinely lowering the bar on the products that aren't in the current crisis. Not every product needs daily attention every week. Explicitly deciding "this one gets nothing this week, on purpose" is different from neglecting it by accident, and it's the only way the math of six products and one person works at all.
Why I'm Not Pretending This Is Solved
I don't think there's a clean answer to running six products alone that doesn't eventually cost something. The honest goal isn't avoiding that cost entirely — it's noticing it faster, recovering from it deliberately instead of by accident, and not mistaking a genuinely sustainable pace for a permanently frictionless one. Some weeks are going to be too much. The system's job is to make those weeks the exception, not to pretend they don't happen.