Managing Multiple Projects as a Solo Developer (The System That Actually Works)

You have three side projects, two client builds, and a main SaaS. On Monday you commit to finishing the onboarding flow. On Wednesday a client emails. On Friday you're knee-deep in a Postgres migration for a project you told yourself you'd pause. Nothing ships. Everything feels active. Welcome to the solo developer's hardest problem.

Managing multiple projects as a solo founder isn't a time-management problem. You already know how to schedule your day. It's a context problem. Every project you touch loads a different mental model into your head — different architecture, different users, different half-finished decisions. The switching cost isn't 15 minutes of "getting back into it." It's the cognitive tax of holding five worlds in your brain and never letting any of them fully render.

Most productivity advice for multi-project work was written for managers. Delegate. Batch. Use OKRs. Block time. When you're the only person on every project, those tactics collapse. You can't delegate what only you understand. You can't batch work across projects that each need deep focus. And OKRs across five projects mean you've just created five ways to feel behind.

What actually works is a system built around context, not hours. Here's how solo developers with multiple concurrent projects can ship consistently — without pretending they're a team of five.

---

Why solo multi-project work fails

Before the system, let's diagnose why it usually breaks. Every solo developer juggling 3+ projects eventually hits the same wall, and naming the wall makes it easier to avoid.

The equal-attention trap

You treat all your projects as if they deserve the same attention. Monday is SaaS morning. Tuesday is client work. Wednesday is the side project. This feels balanced. It ships nothing. Each project gets a thin slice of time that never adds up to meaningful progress — you spend the slice loading context and close the laptop before anything is actually built.

The "I'll just check" context leak

You're working on Project A. A Slack ping from Project B. A customer email from Project C. You "just check" — and thirty minutes later you've answered three questions, left a fourth tab open, and completely lost the thread of Project A. Multiply by five check-ins a day and your most focused hours are shredded.

The secret active-backlog explosion

On paper you have three projects. In reality you have three projects, four "paused" projects, two client promises you haven't fully committed to, and a half-built scraper. Every one of them lives rent-free in your head. They'll pull your attention even when you're not working on them. Nothing is truly paused unless it's explicitly dead.

The illusion of productive parallelism

There's a seductive idea that as a solo founder you should run multiple projects "in parallel" to hedge your bets. In practice, humans don't run tasks in parallel. We interleave. And interleaving with heavy context-loading cost per switch is the worst possible throughput strategy. You don't get the upside of parallelism — you get the friction of parallelism without the speedup.

---

The anchor-workspace model

The foundation of the system is simple: at any given moment, one project is your anchor. Everything else is ambient, paused, or dead. The anchor gets deep work. Everything else gets the margins.

An anchor is not "the project I'm working on right now." It's the project that gets the next two weeks of your best hours. You can only have one anchor at a time. No exceptions.

This model scales to however many projects you have on paper, because it's not about limiting projects — it's about limiting active development. You can technically run 8 projects if 1 is your anchor, 2 are in maintenance, and 5 are paused. What you can't do is have 4 projects all expecting new features this month.

---

The one-active-project rule

The core discipline: at any moment, exactly one project is receiving deep work. This is non-negotiable. When you're at your desk with focused attention, you're on the anchor.

This doesn't mean you never touch other projects. You respond to client emails, fix urgent bugs in revenue-generating apps, and keep the lights on. But those are operational tasks, not development work. The anchor gets the creative, architectural, thinking-hard work.

Here's how the one-active rule survives contact with reality:

Define the anchor for a fixed duration

Pick your anchor for a specific block — typically 2 weeks, never less than 1 week. During that block, you don't debate which project to work on. The decision is already made. This removes the single highest-cost decision from your day.

The 2-week cadence matters. Shorter and you're switching too often to load real context. Longer and you'll lose the ability to respond to new information. Two weeks is long enough to ship a meaningful feature and short enough to pivot if a better opportunity emerges.

Give maintenance projects a scheduled day

If you're maintaining two other projects, give them one day (or half-day) per week on a fixed schedule. "Thursday morning is maintenance." During that block you batch support tickets, review deploys, triage bug reports, and respond to the emails that piled up. Then close those tabs and don't reopen them until next Thursday.

Batching maintenance does two things: it limits the context-switch tax to one switch per week instead of five per day, and it gives your users a predictable response time. "You'll hear back within a week" is a fine SLA for a solo-maintained side project.

Route interruptions to inboxes, not active work

When a Project B issue surfaces while you're anchored on Project A, you don't handle it. You capture it — into whatever inbox that project has — and return to A. The capture takes 30 seconds. The context switch would cost 30 minutes.

The tooling here matters less than the discipline. A Notion page, a GitHub issue, a GritShip card, a text file — any of them work. What kills you is letting the interruption become a context switch by engaging with the details. See it, log it, leave it.

When P1s override the rule

The exception: a true P1 in a maintenance project (payments broken, site down, data loss) overrides the anchor. Fix it, then return. If your "anchor" project gets interrupted by three P1s in a week from your "maintenance" projects, that's a signal — your maintenance projects aren't stable enough to be in maintenance. Either promote one to the anchor and fix the instability, or accept you can't add new projects until your current ones are stable.

---

The weekly cross-project review

Once a week — and only once a week — you zoom out across all your projects. Every Friday afternoon, 45 minutes. This is the only time during the week when multiple projects have your attention simultaneously.

The review has four purposes:

---

The daily focus contract

Your day starts with a 30-second contract with yourself. Before email, before Slack, before the editor: what's the one thing I'm shipping on the anchor today?

Not three things. One thing. In writing. On a sticky note, in a text file, in your task tool — it doesn't matter where, it matters that it's explicit.

This seems trivial. It isn't. The daily contract is the last line of defense against the three failure modes:

• Drift: Without a contract, you start the day by "catching up" (email, Slack, reviewing yesterday). That eats the morning. The contract forces you to start with doing.
• Creep: Without a contract, any task on the anchor feels as valid as any other. The contract forces ranking. The one thing is the most important thing.
• Leakage: Without a contract, when a maintenance project pings, you engage. With a contract, you have something to protect — "I committed to shipping X today" is an argument you can make to yourself when the temptation hits.

The contract gets written in 30 seconds and it runs the whole day. If the one thing ships by 1pm, you get your afternoon back — use it for maintenance, admin, or more anchor work, your call. If the one thing doesn't ship, you know exactly what tomorrow's one thing is.

---

Kill criteria for solo projects

You'll accumulate projects faster than you kill them unless you write down in advance what counts as "dead." Here's a starter set of kill criteria — adopt these or write your own, but have something written.

Kill a project if:

• You haven't shipped anything to it in 90+ days and it isn't generating revenue and you can't name a user who'd notice if it disappeared
• You've picked it up and dropped it three times in a year without shipping meaningful progress
• You can't explain in one sentence why it should exist
• The opportunity cost — what you'd build if you weren't haunted by this — is clearly higher than the expected value
• It was an experiment and the experiment gave you its answer (even if you don't like the answer)

Kill criteria only work if you apply them. Once a quarter, walk the list. For each project on the paused list, apply the criteria honestly. If any criterion fires, kill it. The code stays in GitHub. The project leaves your head.

This is the part solo developers resist hardest. Every project has sunk cost. Every project was once exciting. Every project could still work if you just had more time. The honest truth: if you had more time, you'd start something new anyway. Kill it. Before starting the next one, run it through our solo-founder project risk assessment — the "motivation risk" question alone catches most of the projects that would have become future kill-list regrets.

---

Tooling for solo multi-project work

The system works with any tool, but some patterns make it easier.

One workspace per project, one dashboard across them

The mistake most tools encourage is putting everything in one giant workspace with labels and filters. This collapses the context separation you're trying to build. Each project should feel like its own environment when you're in it.

But you also need a cross-project view — somewhere you can see at a glance the state of every project. This is usually a lightweight dashboard (or just the one-page project map) that lives outside any single project.

Separate inboxes per project

Every project gets its own capture inbox — a backlog or "incoming" column that absorbs interruptions without forcing you to triage them in the moment. When a Project B issue surfaces while you're anchored on A, it goes into B's inbox. You triage B's inbox next Thursday, not now.

A system for priority across projects

For maintenance work that cuts across projects, you need a priority system that works globally. The P1–P4 framework works well here — a P1 in any project beats a P3 in your anchor. A P3 in a maintenance project waits until Thursday batch time.

Keyboard-first tools reduce switching cost

If your tools force mouse-driven navigation, switching between project workspaces costs you 30+ seconds per switch in pure clicks and loads. Keyboard-first tools (Linear, GritShip) let you switch workspaces in under 2 seconds. Over a week with ~20 switches, that's 10+ minutes — and more importantly, the friction doesn't interrupt your thought.

GritShip was built with this exact workflow in mind: one workspace per project, ⌘K switches instantly across them, and keyboard shortcuts assume you're fluent in them, not discovering them.

---

The uncomfortable conclusion

Most solo developers who "can't get anywhere on multiple projects" don't have a time problem. They have a project-count problem. They're running five projects with four of them silently draining focus, and the real answer is to kill two and commit properly to the rest.

The anchor-workspace model works because it's honest about cognitive capacity. You can hold one deep-work project in your head at a time. You can maintain 1–2 projects with batched weekly work. Everything else has to be paused or dead.

If you're a solo developer who feels constantly behind across multiple projects, here's the 30-minute exercise:

1. Write down every project you have open. Every one. Include the "I'll get back to it" projects.
2. For each, label it: Anchor, Maintenance, Paused, or Dead. One anchor only.
3. Write your Kill Criteria at the bottom of the page.
4. Apply the criteria. Kill what qualifies.
5. Set a 2-week timer on your anchor.
6. Tomorrow morning, write your daily focus contract.

That's the system. No new tool, no new process, no 47-point GTD overhaul. One anchor. One focus. One weekly review. One honest kill list.

The projects aren't going to ship themselves. And "working on all of them" is the same as "shipping none of them." Pick the anchor.

---

Frequently asked questions

How do solo developers manage multiple projects at once?

The most effective approach is the anchor-workspace model: one project is the active 'anchor' receiving 70%+ of focused work, 1–2 projects are in scheduled maintenance (batched to a single day per week), and everything else is explicitly paused or killed. Solo developers cannot genuinely parallelize deep work — switching context costs 15–30 minutes each time — so the system is built around limiting active development rather than limiting projects on paper.

What's the best productivity system for a solo founder managing multiple projects?

A three-layer system works best: (1) a daily focus contract committing to one shippable thing on the anchor project, (2) a weekly cross-project review (45 minutes every Friday) to check status, re-confirm the anchor, and kill stalled projects, and (3) a one-page project map listing every project's state. This replaces the common failing approach of allocating equal time to each project, which produces equal amounts of progress on each (usually near zero).

How many projects can a solo developer realistically run?

One active development project at a time, plus 1–2 maintenance-mode projects handled via batched weekly work, plus an indefinite number of paused or dead projects. The constraint isn't hours available — it's cognitive context. Holding multiple architectures, user bases, and half-finished decisions in your head has a hard ceiling. Most solo developers who claim to run 4–5 active projects are actually running 1 and feeling guilty about 4.

How do you switch between projects without losing momentum?

Minimize switches. Instead of switching daily between projects, anchor on one project for 2-week blocks. When you must handle another project (maintenance, urgent bug), batch those tasks into a fixed weekly block (e.g., Thursday morning) so you pay the context-switch cost once instead of five times. For interruptions during anchor work, capture them to the other project's inbox without engaging with the details — return to your current context immediately.

When should you kill a side project?

Apply explicit kill criteria at least quarterly. Common criteria: no shipping in 90+ days, no revenue and no users who'd notice if it disappeared, you've picked it up and dropped it three times without progress, or you can't explain in one sentence why it should exist. Killing doesn't mean deleting the code — it means stopping the story that you'll return to it soon. The cognitive cost of 'paused' projects is often higher than the opportunity cost of killing them cleanly.

How do you prevent burnout when running multiple projects as a solo developer?

Burnout in multi-project solo work is almost always caused by holding too many active projects simultaneously, not by hours worked. Reducing active projects to one anchor and 1–2 maintenance items dramatically reduces cognitive load even if total hours stay the same. Batched maintenance, fixed review cadences, and explicit kill criteria prevent the 'everything is always half-urgent' feeling that drives burnout. The goal is fewer active threads, not fewer hours.

Should solo founders use the same project management tool for all their projects?

Yes, but with strict workspace separation per project. Using one tool with multiple workspaces preserves context (each project feels like its own environment) while giving you a unified cross-project view. Avoid stuffing everything into a single workspace with labels — that collapses the context separation you need. The tool matters less than the separation; what matters most is keyboard-first navigation so switching between workspaces doesn't cost you 30 seconds of friction per switch.