Running 3 projects at once as a solo developer isn't about time management — it's about context management. Here's a productivity system for solo founders juggling multiple projects without burning out or shipping nothing.
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Try GritShip free →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.
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.
68%
of indie hackers
report running 3+ concurrent projects
23 min
Average refocus time
after context switch (UC Irvine)
5x
Daily switches
typical for multi-project solo devs
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.
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.
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.
"I thought I was running three projects. I was actually running one project and being haunted by two."
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 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 is where the shipping happens. 70%+ of your focused hours go here. It's the project you wake up thinking about, the project where you're making weekly, visible progress. One at a time.
Projects that exist, earn revenue or have users, but don't get new features right now. You handle support, bug fixes, and essential operational work. Budget: 2–4 hours per week, preferably batched on a single day.
Projects that you're intentionally not working on. Written down. Dated. Maintenance-only or fully cold. The explicit list matters — until you name a project "paused" in writing, it lives in your head as a half-obligation.
Projects you've killed. Not shelved. Dead. You have no plan to return to them and you're not maintaining the code. Move on. Dead projects don't get a backlog.
💡 One anchor, not three
The single biggest unlock for solo developers with multiple projects is accepting that you can only push forward on one project at a time. The others still exist. They still earn revenue. But meaningful forward motion — the kind that ships a new feature or opens a new market — happens one project at a time.
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 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:
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.
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.
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.
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.
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:
For each project (anchor, maintenance, paused), answer three questions: What shipped this week? What's blocked? What changed in priority? If a project hasn't shipped anything and isn't blocked, that's a signal. Either it's genuinely idle (fine) or it's stalled without you noticing (not fine).
At the end of every 2-week anchor cycle, you choose: keep going or switch. The default is to keep going. You only switch if one of three things is true:
Switching without one of these reasons is just productivity theater dressed up as "rebalancing."
This is the hardest part. If your total project count is growing (not staying flat or shrinking), you're accumulating cognitive debt. The weekly review is where you ask: what should I kill or formally pause?
Killing doesn't mean deleting the code. It means stopping the self-story that you'll come back to it soon. Write "dead" on it. Or "paused until Q3." The explicit label frees the mental space.
Maintain a single document — one page, not a Notion database — that lists every project and its current state. Anchor. Maintenance. Paused. Dead. One line each. Reviewing this weekly is how you notice that the "paused" pile has grown to 7 and it's time for a purge.
ℹ️ The map is the territory
The one-page project map is the single most underrated artifact for solo multi-project work. Without it, you constantly recount in your head ("wait, am I running 3 projects or 5?"). With it, you always know. The physical act of writing the list is what forces honest triage.
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:
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.
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:
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.
The system works with any tool, but some patterns make it easier.
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.
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.
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.
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.
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:
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.