How to Manage Your Backlog as a Solo Developer

Your Backlog Is Lying to You

You've got a backlog somewhere. Maybe it's in Notion. Maybe it's a GitHub project board. Maybe it's a text file called TODO.md that's been growing for six months. Whatever form it takes, I'd bet money on two things: it has more than twenty items, and at least half of them will never get built.

That's not a productivity failure. That's what happens when you apply team-based developer backlog management to a one-person operation. Backlog grooming, story points, prioritization matrices, MoSCoW analysis — these processes exist because teams of eight people need to agree on what to build next. You don't need agreement. You need clarity.

Learning how to manage your backlog as a solo developer means unlearning most of what you've absorbed from Agile, Scrum, and whatever your last company did. Those systems solve coordination problems. You don't have a coordination problem. You have a focus problem. And a bloated backlog is making it worse, not better.

According to the Stack Overflow Developer Survey, the majority of developers work on side projects. But most of those projects never ship. A bloated backlog is one of the reasons — not because developers lack discipline, but because the system they're using was designed for a different context entirely.

Why This Is Harder When You're Working Alone

Here's the thing about solo developer backlog management that nobody talks about: every item on your list is something you came up with. There's no product manager adding requirements you can push back on. No designer proposing features you can evaluate objectively. It's all you. Every idea feels equally important because it came from the same brain.

On a team, backlog prioritization happens through conflict. People argue. Someone says "that's a nice-to-have" and someone else says "no, it's a must-have" and eventually the group settles on a priority. The friction is productive. It forces evaluation.

When you're solo, there's no friction at all. You think of a feature, you add it to the list, and the list grows. You think of another one. The list grows again. Six months later you've got a backlog with forty-three items and you're paralyzed because you don't know where to start. Or worse, you start something new every week because everything on the list looks equally appealing.

The other problem is emotional attachment. You generated these ideas. They feel like commitments. Deleting an item from your backlog feels like admitting the idea was bad, and nobody likes admitting their ideas are bad. So items accumulate. They sit there, aging, getting stale, making your project feel larger and more overwhelming than it actually is.

Atlassian's guide on backlog management notes that even teams with dedicated PMs struggle with backlog bloat. For a solo developer with no external accountability, it's exponentially worse.

I've seen developers with side project backlogs that would take two years of full-time work to clear. These are people who work on their projects a few hours per week. The math doesn't work, but the backlog doesn't care about math. It just keeps growing.

Step 1: Stop Treating Your Backlog as a Commitment

This is the mental shift that changes everything. Your backlog is not a roadmap. It is not a list of things you will build. It is a list of things you might build. Possibilities. Options. A scratch pad.

The moment you start treating your solo developer backlog as a commitment, every addition creates pressure. You feel behind because the list is long. You feel guilty because items sit unfinished. You feel overwhelmed because the total scope of "everything on the list" is massive.

But you never committed to building all of it. You just wrote it down.

Try this reframe: your backlog is a menu, not a contract. When you go to a restaurant, you don't feel obligated to order everything on the menu. You scan it, pick what you want right now, and ignore the rest. That's how your backlog should work. It's a set of options you can choose from, not a set of obligations you're failing to meet.

This is harder than it sounds, and it's central to how to manage your backlog as a solo developer. Especially if you've worked in environments where every backlog item was tracked, estimated, and reported on. Letting go of that mindset takes practice. But once you do, your backlog stops being a source of anxiety and starts being a useful tool.

Step 2: Separate "This Version" From "Someday"

Here's the system that actually works for backlog prioritization solo. Two lists. That's it. No complex priority tiers. No P1/P2/P3 labels. No weighted scoring models. Two lists.

List one: "This Version." These are the items you're actively building right now, for the current version of your project. This list is short. It is specific. It represents real work that will ship.

List two: "Someday." Everything else. Feature ideas. Improvements. Bug fixes that aren't urgent. Cool things you thought of at 2am. Stuff users mentioned that might be worth doing. All of it goes here.

The rule is simple: only "This Version" matters. You work from that list and nothing else. The "Someday" list is a parking lot. You're not ignoring it. You're just not working on it right now.

This separation does something powerful for your psychology. It shrinks your perceived workload from "forty-three things" to "six things." Same backlog, same ideas, but now you can actually see the finish line. And seeing the finish line is what keeps you moving.

When you finish everything on "This Version" and ship, you go to the "Someday" list and pick what goes into the next version. Repeat. That's the whole system. Backlog prioritization solo doesn't need to be more complicated than this.

Step 3: Limit "This Version" Ruthlessly

Five to seven items. That's your cap for the "This Version" list. Not fifteen. Not ten. Five to seven.

If you can't fit it into seven items, you're thinking too big. Either your items are too vague (break them down) or your version is too ambitious (cut it). A "This Version" list with twelve items isn't a version. It's a wish list wearing a version's clothing.

Why five to seven? Because that's roughly what one person can hold in working memory and make meaningful progress on in a reasonable timeframe. More than seven and you start context-switching between items, losing momentum, and feeling scattered. Fewer than five and you're probably not pushing yourself enough, though honestly three focused items is better than nine scattered ones.

The hard part isn't picking the five to seven. It's resisting the urge to add an eighth. You'll finish an item, feel good, and think "I could squeeze in one more thing before this version ships." Don't. Ship with six. Add the seventh to the next version's "This Version" list.

I know this feels limiting. That's the point. Constraints aren't obstacles to your side project backlog. They're the structure that makes progress possible. Without them, you'll keep adding items and never actually ship.

Step 4: Kill Items Older Than 30 Days

Here's a rule that sounds extreme but will save your sanity: if a backlog item has been sitting in your "Someday" list for more than 30 days and you haven't started working on it, delete it.

Not "move it to an archive." Not "deprioritize it." Delete it.

If it was genuinely important, it'll come back. You'll think of it again. A user will request it. You'll hit a problem that makes the feature obviously necessary. And when it comes back, it'll come back with more context and clarity than it had the first time.

If it doesn't come back, it wasn't important. It was a passing idea that felt significant in the moment. Your backlog is full of these. Little sparks of enthusiasm that burned out within a day but left an item sitting on a list for months, taking up mental space and making your project feel bigger than it is.

This is the hardest practice to adopt because it feels wasteful. You're throwing away ideas. What if one of them was brilliant? Here's the reality: brilliant ideas stick. They resurface. They nag at you. The ones you forget about after deleting them? Those were never going to get built anyway. They were dead weight.

I started doing this about a year ago and my side project backlog went from sixty-something items to eleven. Eleven. And not a single deleted item has turned out to be something I actually needed. Not one.

Step 5: Review Weekly, 5 Minutes Max

You don't need a grooming session. You don't need to re-estimate anything. You need five minutes once a week to answer one question: "What is the one thing that moves this project closest to shipped?"

That's the whole review. Open your "This Version" list. Look at what's there. Ask the question. Adjust if needed. Close the list. Go build.

If you're spending more than five minutes on your weekly backlog review, you're doing it wrong. You're probably reorganizing, re-prioritizing, adding new items, or doing whatever makes you feel productive without actually being productive. A review is a check-in, not a planning session.

Here's what a good five-minute review looks like in practice:

• Open the "This Version" list. Are all items still relevant? (30 seconds)
• Is there something on the list that's been sitting untouched for two weeks? If yes, either start it this week or move it back to "Someday." (30 seconds)
• What's the single most important item to make progress on this week? (1 minute)
• Quick scan of "Someday" list for anything that's suddenly become urgent. (1 minute)
• Done. (2 minutes to spare)

The discipline is in keeping it short. The moment your weekly review becomes a 45-minute planning session, you've recreated the team ceremony problem. You're managing your backlog instead of building your project. Those are different activities, and only one of them ships software.

Step 6: Never Groom Alone

Backlog grooming is a team ceremony. It exists so that multiple people can develop a shared understanding of work items, estimate effort together, and align on priorities. It requires different perspectives to be effective. One person talking through their own backlog items out loud is not grooming. It's talking to yourself.

Solo devs don't need grooming. They need a "ship list."

A ship list is what I've been describing as the "This Version" list, but the name matters. Calling it a "ship list" reminds you of its purpose. This isn't a backlog to be groomed and estimated and discussed. It's a list of things that need to happen before you can ship. The name creates urgency. "Backlog" sounds like something you'll get to eventually. "Ship list" sounds like something that needs to be empty by Friday.

If you catch yourself doing solo backlog grooming, like sitting down for an hour to go through every item, add estimates, adjust priorities, and reorganize categories, stop. You're procrastinating. You're doing meta-work that feels productive but produces zero code, zero features, and zero shipped products. It's the project management equivalent of sharpening your pencil for an hour before writing.

FoundStep was designed with this reality in mind. Instead of giving solo developers a mini-Jira to manage, it focuses on the ship list concept, keeping your active work front and center and pushing everything else out of sight until you need it.

The Mistakes That Kill Your Side Project Backlog

Treating Your Backlog as a Roadmap

Your backlog is not a roadmap. A roadmap implies sequence, timeline, and commitment. Your backlog is a pool of ideas with no inherent order. When you treat it as a roadmap, you feel obligated to work through it top to bottom, and you feel behind when you don't.

Roadmaps are for products with users, deadlines, and stakeholders. If you're a solo developer working on a side project, you don't need a roadmap. You need a ship list and a parking lot. That's it.

If you want to think more about how to prioritize features as a solo developer, the key insight is the same: simplify. Every layer of process you add is a layer you have to maintain. And maintenance is time you're not spending building.

Spending Time Organizing Instead of Building

This one is sneaky because it feels like work. You spend Saturday morning color-coding your Notion board, adding tags, creating views, setting up automations. Three hours later, your backlog looks beautiful and you haven't written a line of code.

Developer backlog management should take minutes per week, not hours. If your system requires significant maintenance, the system is wrong. The best backlog system is one you barely think about. A list. Two columns. Five to seven items in the active column. That's it.

I've watched developers build custom Notion templates with linked databases, rollup properties, and formula fields to manage a side project backlog of twenty items. You know what would've been a better use of those four hours? Building four hours worth of features.

If your project management setup takes longer to maintain than the features on your active list, something has gone wrong.

Never Deleting Anything

This is the most common mistake in solo developer backlog management. You add items but never remove them. The backlog only grows. It never shrinks.

After six months, you've got a backlog that represents a year of work. After a year, it represents three years. The psychology of this is terrible. You open your backlog, see eighty items, and feel crushed before you start. So you close it and do something else. The backlog has become a source of dread instead of a source of direction.

Delete aggressively. Delete the items you added three months ago and never thought about again. Delete the "nice to have" features for users you don't have yet. Delete the performance optimization for a page that gets twelve visitors a month. Your future self will thank you.

And if deleting feels too permanent, remember: you're a developer. You can build anything on that list in the future if you actually need it. The code doesn't disappear from your brain just because you removed an item from a list. But the mental overhead of carrying eighty items? That does real damage.

How This Connects to Scope Creep

Backlog bloat and scope creep are cousins. A bloated backlog makes scope creep easier because there's always "one more thing" on the list you could squeeze into the current version. A clean, ruthlessly maintained backlog is a natural defense against scope creep. When your "This Version" list has six items, adding a seventh requires conscious effort. That friction is protective.

FoundStep connects these ideas directly: your ship list is your scope. If it's not on the ship list, it's not in scope. Period. The tool enforces what your willpower alone might not.

FAQ

How should a solo developer manage their backlog?

Split it into two lists: "this version" and "someday." Only "this version" matters. Keep it to 5-7 items max. Kill anything older than 30 days that you haven't started. The entire system should take five minutes per week to maintain. If it takes longer, you're over-engineering your process.

Should solo developers do backlog grooming?

No. Backlog grooming is a team ceremony designed to build shared understanding across multiple people. Solo devs need a 5-minute weekly check: what's the one thing that moves this project closest to shipped? That's your whole grooming session. If you're spending an hour going through your backlog, you're doing meta-work instead of real work.

How many items should be in a solo developer's backlog?

Your active "this version" list should have 5-7 items. Your "someday" list can be any size, but treat it as a parking lot, not a commitment. The "someday" list is where ideas go to wait. Some will survive and move to a future "this version" list. Most won't, and that's fine.

When should I delete items from my backlog?

If you haven't started it in 30 days, delete it. If it was important, it'll come back naturally. If it doesn't come back, it wasn't important. This sounds aggressive, but in practice, almost nothing you delete will turn out to have been necessary. The ideas that matter stick in your brain whether they're on a list or not.

How to Manage Your Backlog as a Solo Developer: Two Lists, Five Minutes, Ship

You don't need a better backlog management system. You need less of one. Two lists, a weekly five-minute check, and the willingness to delete things. That's the whole approach.

Your backlog should fit in your head. If it can't, it's too big. Shrink it until it can. That's the whole answer to how to manage your backlog as a solo developer. Build what's on the ship list and ignore everything else until this version is done.

If you want a tool that enforces this naturally, FoundStep is built around the idea that solo developers need less process, not more. A ship list, not a backlog. Focus, not flexibility. Take a look if your current setup is making you organize instead of build.