Managing multiple side projects without burning out

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

The thing that burns founders out isn't the number of projects — it's the constant switching between them. Every jump from one codebase, one customer base, one mental model to another costs a re-orientation tax, and paying that tax five or six times a day is what leaves you exhausted with nothing to show for it. The fix isn't finding more hours; it's giving each project a clear, current role, protecting blocks of uninterrupted time for whichever one has earned that attention this week, and using a short weekly review — grounded in what's actually growing, not what's shouting loudest — to decide where the next block goes.

Disclosure: this guide is published by SoleOS, a portfolio dashboard built for founders running several products at once, so we obviously have a stake in this topic. The framework below works with a spreadsheet and a notes app just as well as it works with any dashboard — including ours.

Context-switching is the real enemy, not hours

Ten hours spent on one project in a single sitting and ten hours split across six projects in twenty-minute fragments are not the same ten hours. The second version costs more because every switch means reloading context: what was I doing here, what broke, who's waiting on a reply, what did the metrics look like last time I checked. That reload tax is invisible on a calendar but it's where the energy actually goes.

Running many products doesn't inherently cause burnout. Undisciplined switching between them does. A founder running ten mostly-automated apps that get checked in on weekly can feel calmer than a founder running two apps they mentally re-litigate all day long. The goal of everything below is to reduce the number of switches, not the number of projects.

Give every project a defined mode

Pretending all your projects deserve equal attention is how the loudest one — usually whichever is throwing an error right now — quietly wins every day. Instead, assign each project one of four modes, write it down somewhere, and keep it current:

• Active push — this is the project getting your deliberate focus time this cycle. New features, growth work, real investment.
• Maintenance — keep the lights on. Critical bugs and support only, no new scope. It should require almost no thought.
• Experiment — you're testing whether something is worth investing in: a new pricing model, a redesign, a fresh idea. It gets capped time and a hard decision date, not indefinite dabbling.
• Sunset — you've decided to wind it down. The only remaining work is turning off spend, notifying users, or handing it off.

The point of naming modes explicitly is that it forces a decision instead of letting default behavior make one for you. Without it, a maintenance-mode app that breaks on a Tuesday silently becomes today's active-push project, and the thing that was actually compounding gets skipped again.

Time-box instead of task-switching

Once modes are assigned, protect them with your calendar, not your intentions. Give the active-push project a real block — a half day, a full day, or a specific afternoon each week — rather than a little bit of attention scattered throughout every day. Maintenance items get a fixed, short window too (say, thirty minutes on a Friday) instead of being checked reflexively whenever you have downtime.

Rotate which project holds the active-push slot weekly or biweekly rather than daily. The batching is the whole benefit: you load context for one project once, work in it for hours, and don't pay the reload tax again until the next block.

Run a lightweight weekly review

A fifteen-to-twenty-minute review, same time each week, is enough to keep the system honest. Look at three things: which project actually moved (revenue, traffic, signups, rankings) since last week; whether any project has sat in "experiment" past its decision date; and whether the maintenance backlog is creeping into active-push territory. Then decide, explicitly, where next week's focus block goes.

This doesn't need to be elaborate. A shared doc with one line per project — current mode, last week's key number, next decision — does the job. The Founder Playbook covers other lightweight routines like this one if you want more structure without more overhead.

Let data decide, not the loudest signal

Attention naturally flows to whatever complains — a crash alert, a one-star review, an angry email — regardless of whether that project is actually worth the time. The project that deserves your next active-push block is usually the one where an extra week of focus compounds: the one already showing an upward trend in traffic, search visibility, or revenue, not the one demanding fire-fighting.

This is easier to see when you can glance at growth curves across all your products at once instead of logging into five or six separate consoles to reconstruct the picture from memory — which is exactly what a connected portfolio view is for, whether that's SoleOS's or your own spreadsheet pulling the same numbers. If you've already found a project with real momentum, the $500→$1k guide walks through turning that signal into a concrete growth plan rather than just admiring the chart.

Here's the honest caveat: if you're running one or two projects, you can hold their trend lines in your head or in two browser tabs — you don't need a dashboard for that. The unified view starts earning its keep once you're checking more consoles than you can reliably remember without opening them, which for most founders is somewhere around five or more active properties.

Resist shiny-new-project syndrome

A new idea feels like progress because it's all green field — no legacy code, no support backlog, no plateaued growth chart to stare at. That feeling is not information about whether the idea is good; it's dopamine competing with the grind of an existing project's harder, less novel next step.

The rule that keeps this in check: a new idea has to displace something. Either it becomes this cycle's capped experiment slot with a real decision date, or an existing project has to move to sunset first to free the capacity. Don't let your portfolio grow without also freeing a slot somewhere — otherwise every project's time budget just gets thinner.

Automate the maintenance tier so idle projects stay idle

A project in maintenance mode should not require you to think about it. That means uptime and crash alerting instead of manually checking dashboards, billing and renewals handled by Stripe or RevenueCat rather than by you, canned responses for the support questions that repeat, and dependency or security patching on a schedule instead of in reaction to a breach. If a maintenance-mode project is pinging your attention weekly, the automation is incomplete, not the project.

The test is simple: you should be able to say "I don't open that project's admin panel unless something pages me" and mean it. Piping alerts and key metrics from every project into one connected place removes the habit of checking-just-in-case, which is itself a source of switching cost even when nothing is wrong.

Know when to sunset

Some projects should stop being maintained and just stop. Signs it's time: flat or declining metrics for months despite zero active-push investment, a support burden that outweighs the revenue it generates, or a project you find yourself dreading before you even open it. None of that is a personal failure — it's a project that's done teaching you what it had to teach.

Sunsetting doesn't have to mean deleting the repo overnight. Raise the price and let the number of remaining users self-select, hand it off or sell it, open-source it, or shut it down with fair notice to anyone still on it. What matters is moving it out of permanent, unloved maintenance and into a resolved state — a project stuck in limbo still occupies a slot in your head even when it's not occupying your calendar.

Frequently asked questions

How many side projects can one person realistically run?

There's no universal number — it depends on how automated each project is and how many are in maintenance versus active-push mode at once. Founders running ten or more apps usually have most of them nearly fully automated; the real ceiling is closer to one or two active-push projects at a time, since that's what a person can actually hold real focus on. Everything else should sit in maintenance, a capped experiment, or sunset.

Should I work on all my projects every day?

No — spreading a little effort across every project daily is the exact pattern that maximizes switching cost. Rotate the active-push slot across a week or two instead, and let maintenance-mode projects get their fixed, short check-in window rather than constant partial attention.

What metrics should I look at when deciding where to focus next?

Trend matters more than absolute size. A small project growing steadily in traffic, signups, or revenue is usually a better claim on your next focus block than a bigger one that's been flat for months, because the growing one is where an extra week of attention compounds. Once you've identified that project, the $500→$1k guide covers how to actually act on the signal.

Do I need a portfolio tool like SoleOS to do this well?

Not necessarily, especially early on. A notes doc listing each project's current mode and last week's key number works fine for a handful of projects. A unified dashboard starts paying for itself once opening five or six separate consoles becomes the bottleneck itself — at that point, seeing revenue, traffic, and app-store data side by side (you can see what that looks like on the live demo) saves real switching cost rather than just looking tidy.

What's the single most useful thing to do this week?

Write down every project's current mode, honestly. Most founders discover they've been spending active-push effort on a maintenance-mode project out of habit, guilt, or noise from a support inbox — and correcting that mismatch is usually the fastest burnout relief available, well before any tool or process change.