How to Run Multiple Side Projects Without Juggling

The problem was never your ambition. It's that you're trying to juggle when you should be rotating.

You don't run three side projects at once. You run one, keep the others warm, and rotate. One lead project gets your best hours. Every other active project gets a small weekly heartbeat so it never goes cold. Anything that can't get a heartbeat is parked, on purpose and in writing, with a note about what would wake it. Fifteen minutes on Sunday decides whether anything changes roles. That's the whole system. The rest of this piece is how to run it.

If you're reading this with a SaaS in beta, a newsletter that's two issues behind, and a domain you bought at 1 a.m. for an idea you can no longer fully explain, welcome. Most advice for you boils down to "pick one." That's fine advice for people who can. Plenty of builders run better with a few fires going, partly because the fires feed each other: the newsletter markets the app, and the app gives the newsletter something to write about. What's missing is the logistics, and nobody teaches them.

Why side projects quietly die

Side projects rarely die in a dramatic moment. They fade, for four ordinary reasons.

Switching eats the hours you thought you had. Ten spare hours a week, split into an hour a night across three projects, is not ten hours of work. Every session opens with a reload: where was I, what was this function for, and why does the only comment say "fix later"? Worse, the project you just left doesn't leave quietly. In two experiments, people who switched away from an unfinished task kept thinking about it and performed worse on the next one, a hangover the researcher called attention residue (Leroy, 2009). Side projects are always unfinished. That's more or less their defining feature.

Guilt spreads across everything. When all three are equally "active," working on one means neglecting two. Every session comes with a background hum of "shouldn't I be doing the other thing?", which makes every session a little worse. Three active projects: three sources of guilt, zero sources of permission.

Untouched looks exactly like dead. A project you haven't opened in three weeks has no pulse you can check. You don't know whether it's resting or rotting, and the not-knowing repels you, because opening it means finding out. So you don't open it, and the uncertainty compounds.

Projects rarely die by decision. They die because nobody wanted to check on them.

Sessions end at the worst possible spot. You stop when you're tired, which is usually at a bug you can't crack or a paragraph that won't come. The next session starts right there, at the least inviting spot in the whole project, a week later and colder. No wonder opening the laptop can feel like wading into cold water.

The rotation: lead, warm, and parked

The fix is to stop treating your projects as equals. Give each one a role, write the roles down, and change them only on purpose. Four roles cover almost everything: lead, warm, parked, and a maintenance slot for things already shipped.

	Share of your project time	What counts as done this week	When it changes roles
Lead	Most of it: 6 to 8 hours of a 10-hour week, in two or three long blocks	One step someone else could see: a feature merged, a chapter drafted, a page live	It ships a milestone, it's been truly stuck for two weeks, or a real deadline elsewhere outranks it. Not because it got boring. Boring is usually just the middle.
Warm	One heartbeat: 30 to 60 minutes, once a week	One small task that keeps the context loaded, ending with a written next step	It misses its heartbeat two Sundays running (it parks), or the lead hands off (it can step up)
Maintenance	A capped slot, about an hour, for something already shipped. It takes one warm spot.	Support answered, nothing on fire, nothing new built	Users want more than the cap holds (a candidate for lead), or it needs nothing at all (it parks)
Parked	Zero	Nothing. That's the point.	Its wake-up line comes true, and something else steps down to make room

The last column is the one that matters. It's what stops you from re-deciding everything at 9 p.m. on a Wednesday. Roles move in exactly four ways, and only at the weekly check:

Four ways a project changes roles, all decided at the Sunday check. A maintenance slot behaves like a warm one. Between Sundays, a role is a decision you've already made.

The five rules that make it work

Roles are the structure. These five habits keep it standing, and together they cost about fifteen minutes of overhead a week.

Crown one lead.

Exactly one project gets your best hours, your default yes, and most of the week. Not forever, just for now. The crown is never shared: the moment two projects are "both the priority," you're juggling again. Picking a lead can feel like betraying the others, but it's the only arrangement under which they survive, because they stop leaking guilt into each other.

The research fits. Across six studies, when people were committed to one goal, competing goals became harder to bring to mind, and that "goal shielding" helped them pursue the main one (Shah, Friedman and Kruglanski, 2002). One wrinkle is useful for builders: goals that helped the main goal were pushed aside less. A warm project that feeds the lead, like the newsletter that markets the app, sits more easily beside it. Rival goals chasing the same end by another route got pushed aside hardest, one more reason two competing app ideas can't share the crown.

Give warm projects a heartbeat.

A warm project gets one small touch a week: thirty minutes, one task, enough to keep the context loaded and prove there's a pulse. Answer the open issue. Sketch the next screen. Write one paragraph. It isn't progress theater. It's the difference between resting and rotting, and it keeps re-entry cheap for the day the crown comes its way. Fifty heartbeats a year adds up to about twenty-five hours of real work, which is more than most "someday" projects ever get.

A shipped thing in maintenance gets the same kind of slot with a hard cap: answer support, fix what's broken, build nothing new, however good the shower idea was. And if a project misses its thirty minutes two weeks running, that's not a scheduling problem. That's the project telling you it belongs in rule three.

Park it, in writing.

Parking is an explicit decision with three parts: this project is dormant, here's why, and here's what would wake it ("after the launch," "in January," "when the day job's busy season ends"). A parked project costs nothing: no heartbeat, no guilt, no pretending. The graveyard feeling that haunts multi-project people comes almost entirely from projects that were never parked, only abandoned. The difference is one sentence.

That sentence does more than it looks like it does. In a series of experiments, unfinished goals kept intruding on people's thoughts and dragging on unrelated tasks, and making a specific plan for the goal made that interference disappear, before the goal itself was done (Masicampo and Baumeister, 2011). A wake-up line is that kind of plan. It gives the project an appointment, so it can stop knocking.

End every session with a hook.

The last two minutes of a session belong to your future self. Write down the exact next action, ideally mid-thought: "make the retry job skip canceled subscriptions; the test is written and failing" beats "continue billing work" by a mile. Developers will recognize the old trick of leaving a failing test. Hemingway's version, in a 1935 Esquire column, was to stop for the day while the writing was still going well and he knew what would happen next.

The hook helps whatever you do next, too. Across four studies, people who expected to return to unfinished work under time pressure struggled to focus on the task in front of them, and a brief "ready-to-resume" plan, noting where they were and how they'd pick it back up, reduced that residue and kept their performance up (Leroy and Glomb, 2018). Add a when and the hook gets stronger: a meta-analysis of 94 tests found that plans spelling out when, where, and how you'll act had a medium-to-large effect on reaching goals (Gollwitzer and Sheeran, 2006). "Tuesday, 7 p.m.: make the failing test pass" is exactly that kind of plan.

Rebalance on Sunday.

Once a week, fifteen minutes, five questions (they're below, ready to copy). This little ritual is the entire management layer. It replaces the constant hum of "should I be working on the other thing?" with a decision that's already been made, which, as our gentle productivity manifesto argues, hands your attention back to the work. Choosing what to do on a given morning is the daily version of the same idea, and it has its own guide.

One exception: deadline weeks overrule all of this. The nearest hard deadline wears the crown, a second deadline project gets real blocks instead of a heartbeat, and everything else parks until it passes. The system is for normal weeks, and most weeks are normal.

The Sunday rebalance, in fifteen minutes

Here's the check. Copy it into your notes app or onto the back of an index card, and run it on Sunday evening, or whenever your week turns over.

Keep this one

The Sunday rebalance (15 minutes)

1. Hours. How many project hours did I actually have last week? Plan this week with that number, not the hopeful one.
2. Crown. Does the lead keep it? Default yes. It can move only if it shipped a milestone, has been stuck for two weeks, or a real deadline outranks it. Bored doesn't count.
3. Heartbeats. Did each warm project get its touch this week? A second miss in a row means it parks, with a wake-up line.
4. Wake-ups. Has any parked project's wake-up line come true? It can come back as warm, but only if something else steps down.
5. Hooks. For each active project: what's the first move, and when? ("Tue 7 p.m.: make the failing test pass.")

Then write each project's role next to its name and close the notebook. You're done until next Sunday.

Question one is the one people skip, and it does the most work. We're reliably optimistic about our own time. In one set of studies, people underestimated how long their own tasks would take, and in one of those studies the optimism disappeared when they were asked to connect their forecast to relevant past experience (Buehler, Griffin and Ross, 1994). Last week is the most relevant past experience you have. Plan with the hours you had, not the ones you're hoping for.

A real week, start to finish

Priya is a backend engineer with a day job and about nine spare hours a week. Here's her board on Sunday night:

Lead: Nudgebill, a small tool that chases late invoices for freelancers. Nine beta users. Annual billing is half built.
Warm: a cookbook of her grandmother's recipes, typed up from index cards with turmeric thumbprints on them.
Maintenance: a command-line tool that renames photos by date. 140 stars on GitHub, two open issues, capped at an hour a week.
Parked: a modular synth kit, still in its box. Wake-up line: "when Nudgebill has annual billing, or January, whichever comes first."

Sunday, 8 p.m. The rebalance. She planned twelve hours last week and got nine, so she plans for nine. The crown stays with Nudgebill. Two hooks go into her notes: "Tue 7 p.m.: make the retry job skip canceled subscriptions (test written, failing)" and "Wed lunch: type up the dal, the card with the stain."

Monday. Nothing. The day job ran late and she watched two episodes of something. The system doesn't mind, so neither does she.

Tuesday, 7 to 9 p.m. The failing test is waiting, so there's no "where was I?" It passes by 7:25. She spends the rest of the block on the annual plan's checkout, and at 8:58 writes the next hook: "Thu: proration for mid-cycle upgrades. Start with the case where the card fails."

Wednesday, lunch. Thirty minutes of cookbook. Dal typed, card scanned, next hook written: "the chutney with no quantities. Call Mom." The project has a pulse.

Thursday, 7 to 9:30 p.m. Proration is uglier than expected. She stops mid-ugliness, but writes down exactly which case is still broken, so Saturday starts warm instead of cold.

Friday. A stranger opens an issue on the photo tool: Windows paths break it. The itch to fix it right now is enormous. She replies "Thanks, I'll look this weekend," which takes two minutes, and closes the tab. Maintenance has a slot, and Friday night isn't it.

Saturday. Three hours on Nudgebill in the morning, and annual billing ships to all nine beta users before lunch. In the afternoon, forty minutes on the Windows bug: fixed, released, issue closed.

Sunday again. Hours: just under nine, seven and a half of them on the lead. Annual billing was a milestone, so the crown could move, but onboarding emails are the obvious next step and she has momentum. It stays. The cookbook got its heartbeat. Then question four: the synth's wake-up line, "when Nudgebill has annual billing," came true yesterday.

This is where the system earns its keep. Waking the synth means something else has to step down, and nine hours won't stretch. Her grandmother's birthday is in November, so the cookbook stays warm, and the synth stays parked with an honest new line: "January." The decision takes four minutes, and the box on the shelf stops looking at her.

Notice what Priya never did: open all three projects on the same evening.

How many side projects is too many?

The honest limit is set by your calendar, not your ambition. Using last week's real hours, a rough guide:

About 5 hours a week: one lead and one warm.
About 10 hours: one lead and two warm. A maintenance slot counts as one of them.
Full-time on your own work: one lead and three or four warm. Still one lead.
Parked: unlimited. Parking is free.

These are rules of thumb, not research findings, and one test overrides them all: if your warm projects together need more time than your lead, the labels have stopped meaning anything. Park something.

New ideas go straight to parked. Write the idea down, give it a wake-up line, and let Sunday decide. Most ideas look different a week later. The good ones still look good, and now they arrive with a plan instead of a 1 a.m. domain purchase.

Rotation looks slow from one week to the next and fast across a year. Juggling is the opposite: busy every evening, and somehow in the same place by spring.

Should you quit a side project or park it?

Parking is for projects whose time isn't now. Letting go is for projects you no longer want, even in daydreams. Two quick questions tell them apart. If it woke up tomorrow, would you feel glad or tired? And has it slept through three wake-up dates without you once wanting to keep the appointment? Tired, and yes: it's time.

Letting go is a skill, not a failure. In three studies, people who found it easier to step back from goals they couldn't reach, and to put that effort into new ones, tended to report higher well-being (Wrosch and colleagues, 2003). Those studies were correlational, so they don't prove that quitting makes anyone happier. They do suggest that "never give up" is worse advice than it sounds.

A good ending takes about ten minutes. Write a few lines on what you learned and what you'd reuse. Archive the repo with a README that says it's finished, so future-you doesn't have to wonder. If anyone uses it, tell them. Let the domain lapse. Then cross it off with a little ceremony. You didn't fail at the project. You finished deciding about it.

Do you need a solo project management app?

Search for a solo project management app and you'll mostly find team software with the team parts hidden. One person running a few projects needs much less. Whatever you use, paper included, check for four things:

Every project in one view, with its role visible.
A home for the hook on each one, so no session starts cold.
A way to park work without deleting it.
Something that notices silence, so a warm project can't go cold without anyone saying so.

The fourth is the one people forget to ask for, and it's the one this system leans on hardest. In Wardesk, each project gets its own board, and the briefing from Aster, the built-in AI companion, can include heads-ups such as a project that's gone untouched for days. That's the "resting or rotting?" question, asked for you while the answer is still "resting." The paper version works too: one index card per project, the date you last touched it written in the corner, and any card older than a week gets a decision on Sunday.

If you're tempted by a Notion template, go in with your eyes open: building the system can quietly become your fourth side project. We wrote an honest comparison in Wardesk vs Notion, and our guide to life management apps covers what to look for when your projects share a calendar with the rest of your life.

The short version Don't juggle three side projects; rotate them. One lead gets your best hours. Warm projects get a thirty-minute weekly heartbeat. Everything else is parked, in writing, with a wake-up line. End every session with a hook that says what's next and when, and spend fifteen minutes on Sunday deciding whether anything changes roles. Rotation looks slow week to week and fast year to year.

Questions people ask

What is side project management?

It's the logistics of running personal projects around a job or studies: deciding which one gets your hours, keeping the others from going stale, and parking what doesn't fit. Unlike team project management, there's nobody to coordinate, so the real job is protecting your attention. A simple version is one lead project, a weekly heartbeat for the others, and a fifteen-minute check on Sunday.

What is the best project management app for one person?

The one you'll still open at the end of a long day. For solo work, look for every project in one view, a place to write the next step on each, a way to park work without deleting it, and something that flags a project you haven't touched in a while. Team features like permissions, sprints, and status reports are overhead when you are the whole team.

Is there free project management software for one person?

Yes. Many task and project apps have free plans that comfortably cover a handful of personal projects, and a plain text file or a stack of index cards costs nothing at all. Before committing, check the limit on active projects and whether you can export your data. A free tool you trust beats a paid one you avoid opening.

Do I need a Notion template for solo project management?

No, though one can work if you already live in Notion. The risk is spending your project hours building and tweaking the system instead of the projects. If you use one, keep it small: a single table with project, role, last touched, and next step covers everything in this piece.

Can you use a project management app for personal use?

Yes. A side project, a house move, and a wedding have the same shape as work projects: an outcome, a list of steps, sometimes a date. What you can skip is the coordination layer of assignees, sprints, and status reports. Pick something light enough that an update takes seconds, or keeping it up becomes a side project of its own.

Sources

Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes, 109(2), 168–181. doi.org/10.1016/j.obhdp.2009.04.002
Shah, J. Y., Friedman, R., & Kruglanski, A. W. (2002). Forgetting all else: On the antecedents and consequences of goal shielding. Journal of Personality and Social Psychology, 83(6), 1261–1280. doi.org/10.1037/0022-3514.83.6.1261
Masicampo, E. J., & Baumeister, R. F. (2011). Consider it done! Plan making can eliminate the cognitive effects of unfulfilled goals. Journal of Personality and Social Psychology, 101(4), 667–683. doi.org/10.1037/a0024192
Leroy, S., & Glomb, T. M. (2018). Tasks interrupted: How anticipating time pressure on resumption of an interrupted task causes attention residue and low performance on interrupting tasks and how a "ready-to-resume" plan mitigates the effects. Organization Science, 29(3), 380–397. doi.org/10.1287/orsc.2017.1184
Gollwitzer, P. M., & Sheeran, P. (2006). Implementation intentions and goal achievement: A meta-analysis of effects and processes. Advances in Experimental Social Psychology, 38, 69–119. doi.org/10.1016/S0065-2601(06)38002-1
Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the "planning fallacy": Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381. doi.org/10.1037/0022-3514.67.3.366
Wrosch, C., Scheier, M. F., Miller, G. E., Schulz, R., & Carver, C. S. (2003). Adaptive self-regulation of unattainable goals: Goal disengagement, goal reengagement, and subjective well-being. Personality and Social Psychology Bulletin, 29(12), 1494–1508. doi.org/10.1177/0146167203256921

Alex builds Wardesk, a calm home for projects, habits, a private journal, and the trips worth remembering, and writes Field Notes about running a full life without the guilt.

One calm place for the lead, the warm, and the parked

Wardesk gives every project its own board, parks tasks in Someday without deleting them, and lets Aster point out the project that's gone quiet. The free plan holds three active projects, one lead and two warm, and archived projects don't count, so a parked one can wait there.

Try Wardesk free → No credit card. Your data stays yours.

How to Run 3 Side Projects Without Losing Your Mind