How to Manage a Side Project Without Losing Your Mind

The average side project dies at week 6. Not because the idea was bad. Not because the tech was wrong. Because the builder lost track of what to do next. They opened their laptop on a Tuesday night, stared at the codebase, couldn't remember where they left off, and opened Twitter instead.

Side project management isn't about Gantt charts or sprint planning. It's about one thing: knowing what to work on when you sit down. If you solve that problem — and only that problem — your side project's survival rate goes from roughly 15% to something dramatically higher.

This guide is the system. It's drawn from how builders actually ship side projects — patterns from Indie Hackers, Hacker News, and r/SideProject — not from productivity content written by people who've never shipped a weekend project.

What follows is a concrete framework: the one-board system, a 15-minute weekly ritual, and a set of rules for managing multiple projects without burning out. Nothing theoretical. Everything actionable.

---

The side project graveyard

Before building a system, it helps to understand what kills side projects in the first place. It's not what most people think.

Developer forums tell the same story over and over. The failure modes are predictable, and almost none of them involve technical skill.

Scope creep disguised as ambition

You start building a habit tracker. By week 2, you're adding social features. By week 3, you're designing an API for third-party integrations. By week 4, the project feels impossibly large and you haven't shipped the core feature.

This isn't ambition — it's avoidance. Adding features is easier than finishing the hard ones. The new-feature dopamine hit is real: your brain rewards you for starting something novel while the tedious-but-critical work (error handling, edge cases, deployment) sits untouched.

The tell is obvious in retrospect: if your backlog is growing faster than your Done column, you're scoping, not shipping.

No prioritization system

Without a clear "what's next," you default to working on whatever feels fun or easy. The login page gets redesigned three times. The billing integration — the thing that actually matters — sits untouched for weeks.

This is the default mode for most side project builders. There's no product manager telling you what to focus on. There's no sprint goal forcing alignment. You open your editor and drift toward the work that offers the least resistance. Fun work displaces important work, and the project never reaches a shippable state.

Context loss after breaks

This is the silent killer. You take a two-week vacation, come back to your side project, and spend 90 minutes just trying to remember what you were doing. Where was that bug? Which API endpoint was half-finished? What was the next feature?

Without a system that preserves context, every break resets your momentum to zero. A study from Microsoft Research found that developers need an average of 10-15 minutes to regain context after any interruption. For side project builders who haven't touched their code in two weeks, that ramp-up time is more like an hour — often the entire work session.

Working on too many projects at once

The average developer has 3.2 active side projects. "Active" meaning they opened the repo in the last 30 days. In practice, none of them are getting enough focused time to make real progress. Each project gets a scattered hour here and there — enough to feel busy, not enough to ship.

The math is brutal. If you have 8 hours per week for side projects and you split it across 3 projects, each gets roughly 2.5 hours. Subtract context-switching overhead and you're left with maybe 90 minutes of productive work per project per week. That's not enough to maintain momentum on anything meaningful.

Here's a pattern that shows up constantly on Indie Hackers: a developer posts about having "5 projects in progress." The community responds: "Ship one. Kill two. Shelve the rest." It's not callous advice — it's math. Finite hours divided by too many projects equals zero finished products.

---

The one-board system for side project management

The fix is embarrassingly simple. One kanban board per project. Three columns. A strict limit on work in progress. No labels, no priorities, no custom fields. Just cards moving left to right.

This system works because it matches how side projects actually get worked on: in short, inconsistent bursts of time. It's designed for the builder who has 5 hours this week and zero hours next week.

Here's the setup:

Three columns, no more

• Backlog — Everything you might do. Features, bugs, ideas, improvements. Dump it all here. Don't organize it. Don't prioritize it yet. This is your idea parking lot, not a prioritized roadmap.
• This Week — The 3 items you're working on this week. Not 5. Not 8. Three. These are the only cards you look at during the week.
• Done — Completed work. This column exists purely so you can see progress accumulating. Don't underestimate how much this matters for motivation on long-running projects.

Why not more columns? Because every additional column creates a decision point. "In Progress" vs "In Review" vs "Testing" vs "Blocked" — these distinctions make sense for a team where multiple people need to know a task's exact state. When you're the only person working, you already know what state everything is in. More columns mean more overhead for zero additional information.

The WIP limit is the entire system

The strict limit of 3 items in "This Week" is not a suggestion — it's the mechanism that makes everything else work. Here's why:

It forces prioritization. When you can only pick 3 items, you have to decide what actually matters. That billing integration suddenly beats the login page redesign because you know you only get three slots. The constraint does the thinking for you.

It creates visible progress. Moving 3 items to Done every week feels tangible. Moving 1 of 15 items to Done feels like nothing happened. Small numbers create momentum. After a month, your Done column has 12 completed items — concrete evidence that you're building something real.

It prevents overwhelm. A backlog of 40 items is fine — you're not looking at it during the week. You're looking at 3 cards. Three things. That's manageable even after an exhausting day at your real job. You don't need motivation to tackle a list of 3. You just pick the top one and go.

It makes context recovery instant. Come back after a break? Your "This Week" column has 1-3 items in it. That's your entire re-entry point. No digging through notes. No reading old commit messages. Your board is your context.

What good cards look like

Card quality matters more than you'd expect. Here are real examples of the difference:

❌ Bad cards: "Work on auth" / "Fix bugs" / "Update UI" / "Database stuff"

✅ Good cards: "Add Google OAuth login flow with redirect" / "Fix 500 error when user uploads file > 5MB" / "Replace homepage hero section with new copy" / "Add created_at index to tasks table"

The test: if you read the card title after a 3-week break, do you know what to do without opening any other files? If yes, it's a good card. If no, rewrite it.

---

The Sunday 15-minute ritual

The one-board system only works if you maintain it. The good news: maintenance takes exactly 15 minutes per week. Do it on Sunday evening or Monday morning — whenever you'd naturally think about the week ahead.

This ritual is the heartbeat of the system. Skip it for two weeks and your board starts drifting — This Week creeps to 6 items, Backlog grows to 50, and you're back to "where was I?" territory. Do it consistently and your side project essentially runs itself.

The entire ritual fits in a single coffee. Here's each step:

That's the entire system. No retrospectives. No velocity tracking. No burndown charts. Pick 3, do 3, repeat.

The ritual is what separates side projects that ship from side projects that die. Without it, the Backlog grows unchecked, This Week starts creeping past 3 items, and you're back to decision paralysis. With it, you always start the week knowing exactly what matters.

One developer on Hacker News described the effect perfectly: "The ritual takes 12 minutes. Those 12 minutes save me hours of wandering during the week."

---

How to manage multiple side projects

Most builders don't have one side project. They have two or three. The one-board system scales to this, but with one critical rule: only one project gets "This Week" items at a time.

The active/maintenance split

At any given point, you should have:

• One active project — This is the project with 3 items in its This Week column. It gets your focused building time.
• All other projects in maintenance mode — Their This Week columns are empty. You only touch them if something breaks or a user reports a critical bug.

This sounds restrictive. It is. That's the point.

Why single-project focus works

Switching between side projects within the same week is the productivity equivalent of running three 5Ks simultaneously. You never build momentum on any of them. Each context switch costs 15-25 minutes of ramp-up time — and when you only have 5-10 hours per week for side projects, that's catastrophic.

Consider the math. You have 8 hours this week for side projects. If you split across 3 projects:

• 3 context switches × 20 minutes = 1 hour lost to ramp-up
• 7 remaining hours ÷ 3 projects = ~2.3 hours each
• Net productive time per project: roughly 2 hours

If you focus on one project:

• 1 context switch × 10 minutes = 10 minutes lost
• Net productive time: 7 hours 50 minutes on one project

That's nearly 4× more productive time on the project that matters most. After 3 weeks of single-project focus, you've put in ~24 hours of focused work. Three weeks of splitting gives each project ~7 hours. The difference is the gap between "almost shippable" and "barely started."

Monthly rotation (if needed)

If you genuinely need to advance multiple projects, rotate monthly. Spend January on Project A, February on Project B. At the start of each month, do a 15-minute planning session for the new active project and clear the This Week column of the outgoing one.

The monthly cadence works because it's long enough to build real momentum but short enough that no project goes completely cold. And your board preserves context between rotations — when you come back to Project A in March, your Backlog tells you exactly where you left off. No re-reading code. No archaeology through git logs.

What "maintenance mode" actually means

Maintenance mode doesn't mean ignoring a project. It means:

• You respond to user-reported bugs — if someone finds a critical issue, fix it. Budget 1-2 hours max.
• You don't add features — no matter how good the idea is, it goes in the Backlog and waits for the project's active month.
• You don't open the codebase to "just check something" — this always turns into 3 hours of tinkering. If it's not a bug report, it can wait.

The discipline is simple: if the project's This Week column is empty, don't touch it.

---

What to do after a long break

Every side project builder takes breaks. Vacations, busy periods at work, burnout, life events. The break isn't the problem — the re-entry is.

Without a system, coming back to a side project after 2-4 weeks feels like inheriting someone else's codebase. You vaguely remember what you were building, but the specifics are gone. You spend your first session just reading code and trying to reconstruct your mental model. By the time you remember what you were doing, your energy is spent.

This is where most side projects die permanently. The builder takes a legitimate break, comes back, can't find their footing, and never opens the project again. It's not abandonment — it's re-entry failure. And it's entirely preventable.

Why re-entry is so hard without a system

The problem is cognitive, not motivational. When you step away from a project, your brain aggressively prunes the detailed mental model you had. After two weeks, you remember the general shape of the project but almost none of the specifics: which file handles the API integration, what that half-written function was supposed to do, which approach you decided on for the caching layer.

Without external storage of that context, you have to rebuild it from scratch. That means reading code, checking git history, and slowly reassembling the picture. Most builders give themselves one session to do this. When that session feels unproductive — "I didn't build anything, I just read code" — they don't come back for a second one.

Your board is your re-entry point

With the one-board system, re-entry takes about 5 minutes:

1. Open your board. Look at your This Week column. Those 1-3 cards are exactly where you left off.
2. Read the card titles. They should be specific enough to remind you what needs to happen — "Add Stripe webhook for subscription cancellation," not "Billing stuff."
3. Pick one and start. Don't re-plan. Don't re-evaluate priorities. Just pick the top card and start working. You can reassess during your next weekly ritual.

This is the killer advantage of a board over a todo list, a notes app, or keeping things in your head. The board is a snapshot of your project's state at the moment you walked away. It doesn't decay. It doesn't get buried under other notes. It's sitting there, waiting, with exactly the context you need.

The 5-minute re-entry protocol

If you've been away for more than a month, add one extra step before jumping into work:

1. Scan your board — Read all cards in This Week and the top 5 in Backlog (2 minutes)
2. Run the project locally — Make sure it still builds and starts (2 minutes)
3. Pick one card and start — Don't reorganize. Don't add new cards. Just work (1 minute)

The urge to re-plan after a long break is strong. Resist it. Your past self already planned. Trust the board and start building. You'll naturally reassess during your next Sunday ritual.

---

Tools that actually work for side project organization

Not every tool is built for the way side projects work. You need something that loads instantly, doesn't require configuration, and doesn't punish you for disappearing for two weeks. Here's what works, ranked by how well it fits the one-board system.

GritShip

Free, fast, and built for exactly this use case. One board per project, keyboard shortcuts for everything, loads in under a second. The WIP limit philosophy is baked into the design — you get a clean kanban board without the 47 features you'll never use. Setup takes under 2 minutes: create a workspace, add a project, and you're looking at your board. If you want the one-board system described in this article with zero setup friction, this is the closest match.

Best for: Builders who want a dedicated tool that stays out of the way.

GitHub Projects

Good if your side project already lives on GitHub. You can create a board view directly from your repo, link issues to cards, and manage everything from the same place your code lives. It's free for all users and supports custom fields if you want them.

The downside: it's tied to GitHub's interface, which isn't optimized for quick task management. Creating a card takes more clicks than it should, and switching between your board view and your code requires navigating GitHub's increasingly complex navigation. It works, but it doesn't feel fast.

Best for: Developers already living in GitHub who don't want another tool.

Plain markdown in your repo

A TODO.md file in your project root is the zero-dependency option. It works, it's version-controlled, and it travels with your code. Some developers swear by this approach — it's the ultimate lightweight system.

The limitation is that markdown doesn't give you the visual "board" experience — you lose the satisfaction of dragging items to Done, and there's no structural enforcement of a WIP limit. You have to manually maintain the 3-item constraint through pure discipline. It works best as a supplement to a board, not a replacement.

Best for: Minimalists who want zero external dependencies.

Notion, Obsidian, and other note-taking apps

Some developers use Notion databases or Obsidian kanban plugins for side project management. These can work, but they carry a risk: note-taking apps invite complexity. Notion's flexibility means you'll spend a weekend designing the "perfect" project management template with 12 properties, 4 views, and a rollup formula. Obsidian's plugin ecosystem means you'll try 5 kanban plugins before picking one.

If you can resist the urge to over-engineer, these tools are fine. But most builders can't — and that's not a character flaw, it's a design incentive. These apps make customization feel productive.

Best for: Developers already embedded in a note-taking ecosystem who can resist the configuration rabbit hole.

What to avoid for side projects

Skip Jira, Asana, Monday.com, and ClickUp. These tools are built for teams of 10-50 with dedicated project managers. The setup time alone will eat your first two sessions, and the per-seat pricing makes no sense when you're the only user.

More importantly, these tools are designed around team coordination features — sprint planning, resource allocation, cross-team dependencies — that have zero value for a solo side project. Using them will make your side project feel like a corporate obligation. That's the fastest way to kill your motivation.

A useful litmus test: if the tool has a "roles and permissions" page, it wasn't built for you.

---

Common side project management mistakes

Even with a good system, there are traps that catch experienced builders. Watch for these:

Over-engineering your workflow. If you spend more than 20 minutes setting up your project management system, you've already gone too far. The setup should take 5 minutes: create a board, add three columns, add your first 3 cards.

Writing cards that are too vague. "Improve performance" isn't a task — it's a wish. "Add database index to queries on the tasks page" is a task. Vague cards create the same "where was I?" problem you're trying to solve.

Never clearing Done. The Done column is for celebrating, not hoarding. Archive it weekly. If your Done column has 40 items from 6 months ago, it's clutter, not motivation.

Refusing to delete backlog items. Every item in your Backlog has a psychological cost. It sits there reminding you of work you haven't done. If an item has been in Backlog for 6 weeks without being picked for This Week, it's not important. Delete it.

Planning when you should be building. The Sunday ritual is your planning time. The rest of the week is for building. If you catch yourself reorganizing your board on a Wednesday, stop. Open your editor instead.

---

The system in 30 seconds

If you remember nothing else from this article:

1. One board per project. Three columns: Backlog, This Week, Done.
2. Max 3 items in This Week. This is the constraint that makes everything work.
3. 15 minutes every Sunday. Celebrate Done, pick next 3, purge stale items.
4. One active project at a time. Others stay in maintenance mode.
5. Your board is your context. After a break, open it and start working.

Side project management isn't about sophisticated tools or elaborate systems. It's about removing the friction between sitting down and doing the work. A board with 3 items in it does that. A backlog of 47 items in Notion does not.

The system described in this article — one board, three columns, WIP limit of 3, 15-minute weekly ritual — has been used by thousands of indie hackers and side project builders. It works not because it's clever, but because it's small enough to actually stick.

The builders who ship their side projects aren't more disciplined or more talented. They just always know what to work on next. Give yourself that same advantage: set up your board tonight, pick 3 cards, and start building tomorrow.

---

Frequently asked questions

How do I manage a side project with a full-time job?

Use a strict weekly planning ritual that takes no more than 15 minutes. Set up a kanban board with 3 columns (Backlog, This Week, Done) and limit yourself to 3 tasks per week. Work in focused sessions of 1-2 hours rather than scattered 20-minute blocks. The key is eliminating decision fatigue — when you sit down, your board tells you exactly what to work on. Most successful side project builders spend 5-10 hours per week, concentrated in 2-3 sessions.

What's the best way to organize side project tasks?

A simple kanban board with three columns — Backlog, This Week, and Done — is the most effective system for side projects. Keep a strict WIP limit of 3 items in your This Week column. Write specific task titles that describe the exact action needed (e.g., 'Add Stripe webhook for cancellation' instead of 'Billing'). Review and reorganize weekly in a 15-minute planning session. Avoid complex project management tools designed for teams — they add overhead without value for solo builders.

How many side projects should I work on at once?

Focus on one side project at a time. While the average developer has 3.2 active side projects, spreading attention across multiple projects means none of them get enough focused time to reach a shippable state. If you have multiple projects, designate one as active (with a populated This Week column) and keep the others in maintenance mode. Rotate monthly if needed. Single-project focus for 3-4 weeks produces more progress than splitting the same time across three projects.

How do I pick up a side project after a long break?

If you use a kanban board, re-entry takes about 5 minutes: open your board, read the items in your This Week column, pick the top card, and start working. Don't re-plan or re-evaluate during your first session back — just execute on what your past self already prioritized. The board acts as a context snapshot from when you left off. If you don't have a board, spend 15 minutes creating one: skim your recent commits to rebuild context, then pick the 3 most important next steps.

Should I use Jira for a side project?

No. Jira is designed for enterprise teams with dedicated project managers, sprint cycles, and complex cross-team dependencies. For a side project, Jira's setup time alone will consume multiple work sessions, and most of its features (sprint planning, story points, velocity tracking, burndown charts) provide zero value for a solo builder. Use a lightweight tool like GritShip, GitHub Projects, or even a plain TODO.md file in your repo. The best side project tool is one you can set up in under 5 minutes.

How much time should I spend on side project management?

No more than 15 minutes per week. That's enough time for a complete weekly planning cycle: review what you finished (2 minutes), assess what's in progress (3 minutes), pick your next 3 tasks (5 minutes), and purge stale backlog items (5 minutes). If your project management routine takes longer than 15 minutes, your system is too complicated. The goal is to spend your limited time building, not organizing.

What's the difference between a kanban board and a todo list for side projects?

A kanban board with a WIP limit is structurally designed to stay small and manageable. It forces you to move items to Done or delete them, creating a natural constraint on scope. A todo list grows without limit — items accumulate, nothing gets archived, and the list eventually becomes a source of anxiety rather than clarity. The visual board format also makes progress tangible (you can see items moving from left to right) and preserves context for re-entry after breaks.

How do I stop adding features to my side project and actually ship?

Use a WIP limit of 3 items in your active column and a rule: no new features until the current 3 are done. When you get a new feature idea, add it to your Backlog — don't start working on it immediately. During your weekly review, ruthlessly delete backlog items that have sat untouched for 4+ weeks. Define a 'Version 1' scope of no more than 5-7 core features and don't add anything else until those are shipped. Scope creep disguised as ambition is the number one killer of side projects.