How to Manage a Side Project Without Losing Your Mind | GritShip Blog | GritShip
Side ProjectsProductivityWorkflow
How to Manage a Side Project Without Losing Your Mind
Side projects die from disorganization, not lack of skill. Here's a battle-tested system: weekly planning, ruthless scope cuts, and one board to rule them all.
By Imtiaz··26 min read
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
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Before building a system, it helps to understand what kills side projects in the first place. It's not what most people think.
85%
Never finish
their side project
6 weeks
Median lifespan
before abandonment
3.2
Avg active projects
per developer
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. For a concrete system around this constraint, our guide on managing multiple projects as a solo developer lays out the anchor-workspace model this article's "one active project" rule is a simplified version of.
"I don't have a motivation problem. I have a 'where did I leave off' problem. Every time I sit down to work on my project, I spend 20 minutes figuring out what I was doing instead of actually doing it." — r/SideProject
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.
💡 Why not a todo list?
Todo lists grow. They never shrink. A kanban board with a WIP limit is structurally designed to stay small. The board forces you to move things to Done or delete them — a todo list lets you add infinitely without consequence. After 6 months, your todo list has 200 items and opening it triggers dread. After 6 months, your board still has 3 items in This Week.
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:
Step 1: Celebrate your Done column (2 minutes)
Look at what you finished last week. Actually look at it. Solo developers almost never acknowledge their own progress — there's no standup meeting where you announce what you shipped, no team Slack channel to post wins in. If you moved 2-3 items to Done, that's a genuinely productive week. Archive or clear the Done column after reviewing it.
Step 2: Assess your This Week column (3 minutes)
Anything still in This Week that you didn't finish? Be honest about why. If it's too big, break it into a smaller deliverable that you can complete in 1-2 sessions. If you just didn't get to it, it stays for next week — but it counts toward your limit of 3. If the same card has survived 3 consecutive weeks without progress, either break it down further or move it back to Backlog. It's blocking your system.
Step 3: Pick your next 3 items from Backlog (5 minutes)
Fill up This Week to 3 items total. Pick based on what moves the project closest to shippable. Not what's fun. Not what's easy. What matters. Ask yourself: "If I could only ship 3 things this week, what would make the biggest difference?" Those are your picks.
Step 4: Purge stale backlog items (5 minutes)
Scroll through your Backlog. Anything that's been sitting there for 4+ weeks and you haven't felt the urge to work on? Delete it. Not archive — delete. If it was important, it'll come back as a fresh thought. This step is non-negotiable — an overgrown backlog creates the same overwhelm you're trying to avoid. A backlog of 15 items is healthy. A backlog of 80 is a graveyard.
ℹ️ The 15-minute rule
If your weekly planning takes more than 15 minutes, your system is too complicated. Side project management should feel like choosing what to cook for dinner, not filing a tax return. Simple inputs, clear outputs, done.
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.
💡 How to pick your active project
When deciding which project to activate for the month, ask: "Which project is closest to a meaningful milestone?" Ship something small before switching. A project with 3 features left to launch beats one with 30, even if the 30-feature project is more exciting.
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:
Open your board. Look at your This Week column. Those 1-3 cards are exactly where you left off.
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."
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:
Scan your board — Read all cards in This Week and the top 5 in Backlog (2 minutes)
Run the project locally — Make sure it still builds and starts (2 minutes)
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.
💡 Write better card titles
The quality of your re-entry depends on the quality of your card titles. "Fix bug" is useless after a 3-week break. "Fix race condition in websocket reconnection on mobile Safari" tells you exactly what to do. Spend the extra 10 seconds writing specific titles — your future self will thank you.
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 to start, 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. The free plan gives you up to 3 projects with unlimited tasks — perfect for managing a few side projects. If you outgrow that, Pro ($8/month flat) unlocks unlimited projects and power-user features. 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. If you're currently stuck on one of these, our roundup of lightweight Jira alternatives for small teams covers the escape options.
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:
One board per project. Three columns: Backlog, This Week, Done.
Max 3 items in This Week. This is the constraint that makes everything work.
15 minutes every Sunday. Celebrate Done, pick next 3, purge stale items.
One active project at a time. Others stay in maintenance mode.
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.