The Solo Developer's Guide to Project Management Without the Bloat | GritShip Blog | GritShip
WorkflowSolo DevProductivity
The Solo Developer's Guide to Project Management Without the Bloat
Most PM advice is written for teams. Here's the definitive guide for solo developers: a minimal system, a 15-minute weekly ritual, and the discipline to stop over-engineering your workflow.
By Imtiaz··21 min read
The best project management system for a solo developer is the one you'll actually use for more than two weeks. Not the one with the most features. Not the one your favorite indie hacker tweeted about. The one that takes less than 15 minutes a week and never makes you feel like managing your project is a second job.
Most project management advice is written for teams. Sprint planning assumes multiple people. Standup meetings require an audience. Story points need a group to estimate. When you strip all of that away, what's left for the developer who's building alone?
This guide answers that question. It's based on how solo developers actually work — drawn from hundreds of real conversations across Hacker News, Indie Hackers, Reddit, and DEV.to — not how productivity gurus think they should.
The solo developer's PM paradox
Here's the trap almost every solo developer falls into at least once:
You're building a side project. Progress is good. Then you think: "I should get organized." So you spend a Saturday evaluating Notion vs. Trello vs. Linear vs. ClickUp. You pick one. You configure boards, labels, priorities, custom fields. You create a backlog of 47 tasks. You feel productive.
Then Monday comes. You open the tool, stare at 47 tasks, and close it. You open your editor and start coding whatever feels right. The PM tool gathers dust. Two months later, you try again with a different tool. The cycle repeats.
"When I decided to create a workflow with project management I had this sinking feeling that it might just be avoiding to work." — Solo developer, DEV.to
This isn't a discipline problem. It's a design problem. You're applying a system built for teams of 10–50 to a team of 1. The overhead that's justified when coordinating multiple people becomes pure waste when you're the only person doing the work. The structural reason enterprise tools keep feeling wrong at solo scale is covered in why every PM tool is built for teams of 50.
30%
Use plain text
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Research across developer communities reveals a striking pattern: the most productive solo developers use the simplest possible systems. Roughly 30% manage their work entirely in plain text or markdown files. Another 25% use a basic kanban board. Only about 10% use a commercial PM tool like Jira or Linear. And the most effective among them spend less than 15 minutes per week on project management.
Why team-based PM fails for solos
Before building a system that works, it helps to understand why the standard approaches don't.
Sprint planning is theater for one
Sprints exist to synchronize a team's work into predictable delivery cycles. When you're solo, there's no one to synchronize with. The concept of "committing" to a sprint scope is meaningless when you're the only person who can change it at any time. Solo developers who adopt sprints typically abandon them within a month because the ceremony produces no value.
Story points measure the wrong thing
Story points are a communication tool. They help a team build shared understanding of relative effort. When you're the only estimator and the only executor, you already have perfect information about how hard something feels. You don't need a Fibonacci-scale proxy for what you already know intuitively.
Backlogs become graveyards
In a team, a product manager curates the backlog — prioritizing, grooming, and removing stale items. Solo developers don't have a product manager. Their backlogs grow unbounded. Every idea, feature request, and "someday maybe" goes in. Within weeks, the backlog has 80+ items and looking at it triggers anxiety, not clarity. The P1–P4 prioritization framework is the lightweight substitute for the product manager you don't have.
Velocity tracking is self-surveillance
Tracking your velocity as a solo developer is like tracking your step count while running alone — the number doesn't help you run faster. Worse, it creates a gamification dynamic where you're tempted to split tasks into smaller units to make the numbers look good, which is time spent on the PM system instead of on the actual work.
ℹ️ The exception
If you're a solo developer billing clients by the hour or reporting to stakeholders, some lightweight tracking makes sense. But even then, a simple time log and a list of completed items replaces 90% of what PM tools offer.
The minimal solo dev system
Here's the system. It has three parts: a board, a ritual, and a rule. Everything else is optional.
Part 1: The 3-column board
Your entire project management lives in three columns:
To Do — Things you've decided to build next. Not "someday." Not "maybe." Things you're committed to building in the near future. Keep this list under 10 items. If it grows past 10, you're not prioritizing — you're hoarding.
In Progress — Things you're actively working on right now. This column has a strict limit: 2 items maximum. Not 5. Not "however many I can juggle." Two. This is the single most important rule in this entire system. It prevents context-switching, forces completion before starting new work, and makes your current focus instantly visible.
Done — Things you've shipped. Move items here when they're deployed, not when the code is written. "Done" means a user can see it. Review this column weekly for a motivational boost and to track real progress.
That's the system. Three columns. Under 15 total active items. A WIP limit of 2.
You can implement this in any tool: GritShip, Trello, Linear, GitHub Projects, a markdown file, or sticky notes on your wall. The tool matters less than the structure.
💡 Why the WIP limit of 2 matters so much
Research on work-in-progress limits shows that limiting active tasks dramatically increases completion rate and reduces cycle time. For solo developers, the benefit is even more pronounced: every task you start but don't finish occupies mental RAM. Two active tasks means you always know exactly what you're doing and what's next. When one gets blocked, you switch to the other. When both are done, you pull from To Do.
Part 2: The 15-minute weekly ritual
Every week — same day, same time — you do a 15-minute review. Not 30 minutes. Not an hour. Fifteen minutes. Set a timer if you need to.
Here's what happens in those 15 minutes:
Minutes 1–5: Review Done. Look at what you shipped last week. This isn't vanity — it's calibration. If you shipped 3 things, that's your real weekly throughput. Not your estimated throughput. Not your hoped-for throughput. Your actual speed. Accept it and plan accordingly.
Minutes 5–10: Review In Progress. Are your active items still the most important things? If something has been In Progress for more than a week, ask: is it stuck, or is it too big? If it's stuck, identify the specific blocker. If it's too big, split it. A task that takes more than a few days is probably 2–3 tasks wearing a trench coat.
Minutes 10–15: Update To Do. Based on what you shipped and what's in progress, pick the next 1–3 items for your To Do column. Remove anything that's been sitting there for 3+ weeks without being started — if you haven't prioritized it in three weeks, it's not a priority.
That's the entire ritual. No sprint planning ceremony. No backlog grooming session. No velocity calculation. Just 15 minutes of honest assessment.
Part 3: The "one thing" daily rule
Every morning, before you open your editor, answer one question: "What's the one thing I'll ship today?"
Not three things. Not a prioritized list. One thing. Write it down somewhere visible — a sticky note, the top of your terminal, the first line of your daily scratch file.
This isn't a task management technique. It's a focus technique. Most solo developers lose hours each day deciding what to work on, switching between tasks, and context-shifting. The "one thing" rule eliminates that decision cost entirely. You already decided. Now execute.
"I used to start every day opening Notion and spending 20 minutes reorganizing my tasks. Now I write one thing on a sticky note and start coding. I ship twice as much." — Developer, Hacker News
The tasks you shouldn't track
This is where most solo dev PM guides go wrong: they tell you to track everything. Every bug. Every idea. Every "nice to have." That's how backlogs become graveyards.
Here's what not to put in your system:
Bugs that take less than 30 minutes to fix. Just fix them. Creating a task, categorizing it, and tracking it takes longer than the fix itself. If you notice a bug during development, fix it now. If you notice it during testing, fix it now. Don't create a task for something you can do in the time it takes to create the task.
Ideas you "might" build someday. Your PM tool is not an idea journal. Ideas go in a separate document — a "someday" file, a notes app, whatever. The PM system only holds things you've decided to build. Mixing ideas with commitments dilutes both.
Tasks with no clear definition of done. "Improve the dashboard" is not a task. "Add a revenue chart to the dashboard" is a task. If you can't describe what "done" looks like in one sentence, the task isn't ready. It's an idea pretending to be a task.
Maintenance work you do automatically. You don't need a task for "deploy to production" or "run tests" or "update dependencies." These are habits, not tasks. Tracking them clutters your board with things that aren't actually work.
Should you track it?
New feature (> 1 hour of work)9/10
Significant bug (impacts users)8/10
API integration / third-party work8.5/10
Content or copy changes6/10
Quick bug fix (< 30 min)2/10
Vague improvement idea1.5/10
Routine maintenance1/10
Tool setup / PM configuration0.5/10
Managing multiple projects
Most solo developers aren't working on just one thing. You might have a SaaS product, a freelance client, a side project, and some open-source contributions. Managing multiple projects as a solo developer requires a different approach than managing one project in a team.
The simplest approach: Separate boards, shared ritual
Give each project its own 3-column board. Don't try to merge them into one mega-board with tags and filters — that's complexity for complexity's sake.
During your weekly 15-minute review, scan all boards. But here's the key: assign each project a day or time block, not a priority number. Instead of "Project A is priority 1, Project B is priority 2," think "mornings are for the SaaS, afternoons are for the client project."
Time-blocking by project eliminates the most expensive decision a solo developer makes: "which project should I work on right now?" If it's Tuesday morning, you work on the SaaS. Decision made.
The "active project" limit
Just like tasks have a WIP limit, projects should too. As a solo developer, you can meaningfully advance 2–3 projects at most. Everything beyond that is context-switching overhead that reduces your output on all of them.
If you have more than 3 active projects, you're not managing 5 projects — you're managing 0 projects slowly. Pick 2–3, park the rest, and revisit quarterly. Our dedicated guide on managing multiple projects as a solo developer pushes this further with the anchor-workspace model — the honest version of this rule is actually one active project at a time.
💡 The parking lot
Create a "Parked Projects" list somewhere outside your active boards. When you finish one active project or a project naturally pauses (waiting on a client, seasonal product, etc.), pull one from the parking lot. This gives you permission to say "not now" without saying "never."
Tool selection: A brutally honest guide
The tool is the least important part of this system. But since you're going to pick one anyway, here are honest recommendations based on how you actually work:
If you're already in a code editor all day
Use GitHub Projects or a markdown file. Your context is already in the terminal and editor. Adding a browser-based PM tool means context-switching. GitHub Projects keeps tasks alongside your code. A TODO.md file in your repo root costs zero context switches.
If you want a visual board with zero setup
Use GritShip or Trello. Both provide a kanban board in under 2 minutes. GritShip is built specifically for developers (keyboard-first, GitHub integration, faster). Trello is more general-purpose but universally understood. Neither requires configuration to be useful on day one.
If speed is your top priority
Use Linear. Nothing matches Linear's interaction speed. Every action has a keyboard shortcut. The interface responds in milliseconds. If the half-second delay in other tools bothers you, Linear is worth the $8/month even as a solo developer — assuming you'll exceed the 250-issue free cap.
If you want total ownership and privacy
Use Plane (self-hosted) or Vikunja. Both are open-source and run on your own infrastructure. Plane is more polished with a Linear-like experience. Vikunja is lighter and runs as a single binary. Zero recurring cost, complete data ownership.
If none of these feel right
Use a text file. Seriously. A TODO.md file in your project root with a few lines of markdown is a perfectly valid PM system. If that's what you'll actually use consistently, it beats an abandoned Notion database every day of the week.
Solo developer tool recommendations
TODO.md
Minimal
Absolute minimalists
Setup: 10 secondsFree: N/APaid: FreeGitHub: Lives in repo⌨️ Keyboard-first
Setup: < 15 minFree: Unlimited (self-host)Paid: FreeGitHub: Good
The anti-patterns: What not to do
Every system has failure modes. Here are the ones that catch solo developers most often:
The setup spiral
You spend more time configuring your PM tool than using it. Custom fields, automations, integrations, templates — each one feels productive but produces zero shipped code. If you've spent more than 30 minutes setting up your PM tool, you've already over-engineered it.
The fix: Set a 30-minute cap on initial setup. Whatever state the tool is in after 30 minutes is your starting point. You can always add more later — but you probably won't need to.
The infinite backlog
Your To Do list has 60+ items. Opening it feels overwhelming. You avoid looking at it, which means you avoid using the tool, which means you lose track of what's important.
The fix: Hard cap your To Do at 10 items. Everything else goes in a separate "Ideas" list that you review quarterly, not weekly. If an idea has sat in the Ideas list for 6 months without being promoted to To Do, delete it. If it was important, it'll come back.
The tool-hopping cycle
You've tried Notion, Trello, Linear, Todoist, ClickUp, and Obsidian in the past year. Each time, you migrate your tasks, configure the new tool, and feel a rush of fresh-start energy. Two weeks later, the shine wears off and you start eyeing the next tool.
The fix: Commit to one tool for 3 months, minimum. The productivity gains from tool mastery far outweigh the marginal feature differences between tools. The best tool is the one you've used long enough to stop thinking about.
The phantom urgency
Everything is marked "high priority." Every task feels urgent. You start the day with 5 urgent items and end it having completed 1, feeling like a failure despite shipping real work.
The fix: Abolish priority labels entirely. Instead, use column position: the top item in your To Do column is what you do next. Period. If something truly urgent comes in, it goes to the top and everything else moves down. No labels, no color codes, no P0/P1/P2 taxonomy. Just position.
The 5-minute daily workflow
Here's what a healthy solo dev PM workflow looks like in practice:
Morning (2 minutes): Open your board. Look at In Progress. That's what you're working on today. If both items are done, pull the top item from To Do. Close the board.
During work (0 minutes): Don't open your PM tool while coding. It's a context switch that breaks flow. If you think of something to add, jot it on a scratch pad and add it later.
End of day (3 minutes): Move completed items to Done. If you thought of new tasks during the day, add them to To Do (but only if they pass the "clear definition of done" test). Glance at tomorrow's priorities. Close the board.
Total daily PM time: 5 minutes. Over a 5-day work week, that's 25 minutes — less than a single standup meeting.
5 min
Daily PM time
2 min morning + 3 min evening
15 min
Weekly review
one session per week
~50 min
Total PM per week
vs. 4+ hours in enterprise tools
Compare that to what enterprise PM tools demand: daily standups (15 min), sprint planning (1–2 hours biweekly), backlog grooming (1 hour weekly), retrospectives (1 hour biweekly). For a team, that overhead is justified. For a solo developer, it's absurd.
When to upgrade your system
The minimal system works until it doesn't. Here are the signals that you've outgrown it:
You're consistently forgetting tasks. If important work is falling through the cracks despite using your board, you might need subtasks or a more structured tool.
You're collaborating with others. The moment a second person needs visibility into your work — a co-founder, a contractor, a client — you need a shared tool, not a text file.
You're managing more than 3 active projects. At this point, cross-project visibility becomes valuable. A tool with multi-project views (like Linear or GritShip) starts earning its overhead.
Your projects have external dependencies. Waiting on API approvals, design assets, or client feedback introduces blockers that benefit from tracking. A "Blocked" column becomes worthwhile.
You're shipping to users on a schedule. If you're doing regular releases with changelogs, milestones or release tracking adds real value.
When you hit these signals, upgrade incrementally. Add one column ("Blocked"). Add one feature (subtasks). Don't rebuild your entire system — extend it. The goal is always the minimum viable process that keeps you shipping.
The philosophy behind less
There's a deeper principle at work here that goes beyond project management.
Solo developers who ship consistently share a common trait: they've made peace with imperfect systems. They don't have the "perfect" PM setup. Their kanban board has items that are vaguely worded. Their backlog isn't groomed. Their weekly review sometimes gets skipped.
And they ship anyway.
The developers who struggle are the ones who believe that better organization will unlock better output. So they spend hours perfecting their Notion database, crafting the ideal tag taxonomy, and building automation rules that fire when a task moves between columns. The system becomes the product. The actual product gathers dust.
The uncomfortable truth is that project management for a solo developer is a solved problem. The solution is: know what to build next, build it, and mark it done. Everything beyond that is optimization — and premature optimization of your PM system is just as wasteful as premature optimization of your code.
Keep it minimal. Keep it fast. Keep shipping.
Frequently asked questions
How should a solo developer manage projects?
The most effective system for solo developers is a 3-column kanban board (To Do, In Progress, Done) with a WIP limit of 2 active tasks, a 15-minute weekly review, and a daily 'one thing' focus rule. This system takes about 5 minutes per day and 15 minutes per week. Tools like GritShip, GitHub Projects, or even a markdown file can support this workflow.
Do solo developers need a project management tool?
Not necessarily. About 30% of productive solo developers manage their work with plain text files or markdown. A dedicated PM tool becomes valuable when you're managing multiple projects, collaborating with others, or finding that tasks fall through the cracks. The key is using the minimum system that prevents lost work — for many solo devs, that's simpler than you'd expect.
What's the best kanban setup for one person?
Three columns — To Do (max 10 items), In Progress (max 2 items), and Done. The 2-item WIP limit on In Progress is the most critical element: it forces you to finish work before starting new work, prevents context-switching, and keeps your focus clear. You can add a 'Blocked' column later if needed, but start with just three.
How much time should a solo developer spend on project management?
About 50 minutes per week total: 5 minutes per day (2 minutes morning review, 3 minutes end-of-day update) plus a 15-minute weekly review. If your PM overhead exceeds an hour per week as a solo developer, your system is too complex. Compare this to enterprise approaches that can consume 4+ hours weekly in ceremonies.
How do solo developers prioritize tasks?
The simplest effective method is column position: the top item in your To Do column is your next task. No priority labels, no P0/P1/P2 categories. When something new comes in, decide where it goes in the list relative to existing items. This eliminates the overhead of maintaining a priority system and forces a single ranked list instead of multiple items all marked 'high priority.'
How do you manage multiple projects as a solo developer?
Give each project its own board and limit active projects to 2–3 maximum. Instead of ranking projects by priority, assign each a time block (e.g., mornings for Project A, afternoons for Project B). This eliminates the daily decision of 'which project should I work on?' Park additional projects in a separate list and revisit quarterly.
Is Notion good for solo developer project management?
Notion can work, but most solo developers over-engineer their Notion setup — spending more time configuring databases and templates than doing actual work. If you use Notion, keep it simple: a single kanban board view with no custom properties beyond a status column. But purpose-built tools like GritShip or GitHub Projects are faster to set up and use for pure project management.
How do you avoid the infinite backlog problem?
Hard-cap your To Do list at 10 items. Everything else goes in a separate 'Ideas' file that you review quarterly, not weekly. Any idea that sits in the Ideas list for 6 months without being promoted gets deleted — if it was important, it will resurface naturally. This keeps your active board focused on commitments, not wishes.
What's the biggest project management mistake solo developers make?
Over-engineering the system. Solo developers frequently spend more time evaluating tools, configuring boards, and maintaining their PM setup than they save in productivity. The most common pattern is the 'tool-hopping cycle' — trying a new tool every few months and losing momentum during each migration. Commit to one simple system for at least 3 months before changing anything.