Why Kanban Fails Solo Developers

Kanban Is Great. Just Not for You.

Kanban works. It works at Toyota, where it was invented to coordinate thousands of workers across assembly lines. It works at software companies with 15-person engineering teams who need to visualize bottlenecks and balance workloads across multiple people. It works anywhere there are multiple workers, multiple stages, and a need to optimize flow between them.

What it doesn't work for is one person sitting alone with a laptop trying to finish a side project. Understanding why kanban fails solo developers starts with understanding what makes it work for teams.

I know that's a bold claim. Personal kanban has an entire book written about it. Trello made the three-column board the default interface for project management. Every productivity YouTuber has a video showing their "perfect kanban setup." But here's the thing: what most solo developers call "kanban" has almost nothing in common with actual Kanban. They've taken a system designed for coordinating teams and stripped out every mechanism that makes it function. What's left is a to-do list displayed horizontally, and calling it kanban doesn't change that.

Discussions on Hacker News about productivity methods consistently surface the same pattern: developers set up kanban boards, run them for a few months, and then quietly abandon them because moving cards around never translated into shipping products.

This is why kanban fails solo developers. Not because the system is bad, but because the system requires conditions that a solo developer cannot provide.

How Kanban Is Supposed to Work

Before I explain why kanban doesn't work solo, it's worth understanding what real Kanban actually does. Most developers have a vague sense of "cards on a board," but the cards are the least interesting part.

Kanban originated at Toyota in the late 1940s. Taiichi Ohno developed it as a scheduling system for just-in-time manufacturing. According to Atlassian's Kanban guide, the core principle is "visualize work, limit work in progress, and maximize flow." Workers would attach cards to parts as they moved through the production line. When a downstream station pulled a part, the card was sent back upstream as a signal to produce another one.

The key word there is "pulled." Kanban is a pull-based system. Downstream stations pull work from upstream stations when they have capacity. Nobody pushes work onto someone else's plate. This is fundamentally different from how most people use kanban boards, where you create a card and push it from left to right.

The other critical piece is WIP limits. Work-in-progress limits cap how many items can exist in any column at once. If the "Testing" column has a WIP limit of 3 and there are already 3 items there, nobody can move anything into testing until something moves out. This is the mechanism that prevents bottlenecks.

WIP limits across multiple people are what make Kanban a system, not a board. Without them, you just have a visual list.

Flow optimization is the third piece. By watching where cards pile up, teams can identify which stage is the bottleneck and allocate resources accordingly. The board makes the problem visible. The team makes the fix.

Notice the pattern: Kanban requires multiple workers, pull-based scheduling between them, WIP limits that create back-pressure, and flow optimization across stages. A kanban solo developer has none of these. There's no one to pull from, no one to push back on, no bottleneck to identify because every stage is the same person.

Why It Breaks Down for Solo Developers

Now that we've covered how the system is supposed to work, let's look at the specific ways it falls apart when you try to use it alone.

WIP limits don't mean anything when you're one person

WIP limits exist to balance load across a team. When your "In Progress" column has a WIP limit of 3, it means the team collectively should only be working on 3 things at once. This prevents context switching and ensures work flows through the system instead of piling up.

When you're alone, you're always working on one thing. You might have 3 cards in "In Progress," but you're not working on 3 things simultaneously. You're working on one and ignoring the other two. The WIP limit isn't constraining anything. You already have a natural WIP limit of 1, because you're one person with one brain.

I've seen developers set a WIP limit of 2 on their personal kanban board and feel disciplined about it. But what does that actually mean? It means you have 2 cards in a column instead of 5. You're still context-switching between them. The limit is decorative.

Real WIP limits create back-pressure across a team. Your personal WIP limit creates a number on a screen.

Cards accumulate in "To Do" forever

Open your Trello board right now. I'm guessing your "To Do" column has somewhere between 20 and 60 cards in it. Some of them have been there for months. A few might be from a different project entirely.

This is one of the biggest personal kanban problems. Without a team to create pressure, your backlog grows without bound. In a team context, a product manager triages the backlog, removes stale items, and forces prioritization. In your personal board, cards check in but they never check out.

You keep adding ideas because it feels like progress. "I captured the thought, so I'm being productive." But a To Do column with 47 items is not a plan. It's an anxiety generator. Every time you open the board, you see everything you haven't done, and your brain tries to hold all of it at once.

A real Kanban team would look at a backed-up To Do column and say "we need to stop adding work and start finishing work." You look at it and add another card.

Moving a card to "Done" is not shipping

Here's a scenario that might feel familiar. You drag a card from "In Progress" to "Done." There's a satisfying little animation. You feel good. You did a thing. Then you drag another card into "In Progress" and start working on that.

Two weeks later, your "Done" column has 14 cards in it and your project still isn't shipped. The cards are done. The project isn't.

This is the difference between task completion and project completion, and a kanban solo developer setup optimizes for the wrong one. The board rewards you for finishing individual tasks. But nobody cares about individual tasks. Your users care about the product. Kanban doesn't have a concept of "shipped." It has a continuous flow of cards moving from left to right, forever. That works for a team handling incoming support tickets or feature requests, where there's always more work. It doesn't work for a solo developer trying to finish a specific project by a specific date.

There's no scope boundary

This is maybe the most insidious problem with kanban for one person. A kanban board has no concept of a project boundary. It's a continuous flow system. Cards come in on the left, move to the right, and new cards replace them. There's no "this is the complete list of things required to ship."

So you keep adding cards. Monday you add "implement user auth." Tuesday you add "add dark mode." Wednesday you add "build settings page." By Friday you have 12 new cards and the project scope has doubled. The board doesn't push back. It happily accepts every card you throw at it.

This is the opposite of what solo developers need. Solo developers need hard boundaries. A fixed list of things to build, a clear definition of done, and friction against adding anything new. I wrote about this in detail: how to avoid scope creep as a solo developer. Scope creep is the number one project killer for indie developers, and kanban boards actively enable it.

Compare this to a simple numbered list with 7 items. You can see the entire scope at a glance. Adding item 8 feels like what it is: scope expansion. On a kanban board, adding card number 48 to a column of 47 is invisible.

Kanban optimizes for throughput, not completion

Kanban measures velocity in terms of throughput: how many cards move through the system per week. That's the right metric for a team processing an ongoing stream of work. Customer support tickets, bug reports, feature requests. In those contexts, you want maximum throughput because the work never ends.

But your side project has an end. Or at least, it should have an end. You don't want maximum throughput. You want completion. You want to get from "nothing" to "shipped" as fast as possible. Those are different goals that require different tools.

Throughput-focused thinking is another reason why kanban fails solo developers. It encourages you to pick easy tasks (more cards moved per day!) instead of tackling the hard, important ones. You're moving cards, but you're not moving the project forward.

What to Do Instead

So if kanban doesn't work solo, what does?

The answer is boring, and that's how you know it's right. You need a locked scope list with binary states. No columns. No "In Progress." No "Blocked" or "In Review" or "Ready for QA." Just two states: not started and done.

Here's why the "In Progress" column is unnecessary when you're one person: you already know what you're working on. It's the thing you're working on right now. You don't need a column to tell you that. The board isn't providing information you don't already have. When you stop working on something, it's either done or it's not started. There is no in-between for a solo developer.

Your scope list should have a fixed number of items. Seven is a good ceiling. Each item represents a feature or capability that must exist for the project to ship. When every item says "done," you ship. That's the whole system.

The hard part is the lock. Once you write the list, you cannot add to it without removing something. New ideas go on a separate v1.1 list. If something truly must be in v1, you have to bump something else out. This forces prioritization in a way that kanban boards never do. I wrote about managing your backlog as a solo developer with this exact approach.

FoundStep was built around this idea. Instead of giving you an infinite board with infinite columns, it gives you a finite scope with binary task states. The friction against scope expansion is the feature, not a limitation. When your project management tool makes it easy to add more work, you'll add more work. When it makes adding work hard and finishing work obvious, you ship.

This isn't a new idea. It's basically how every successful solo developer I've talked to actually works, even the ones who claim to use kanban. They have a mental list of the 5 to 8 things they need to build. They work through it linearly. When it's done, they ship. The kanban board is just window dressing.

Kanban Board vs Shipping System: A Direct Comparison

When you get a new feature idea:

• Kanban: Add a card to the backlog. Two seconds, zero friction.
• Shipping system: Ideas go to a v1.1 list. Current project scope stays locked.

When you lose momentum:

• Kanban: Cards sit in "In Progress" indefinitely. Nobody notices.
• Shipping system: Your locked scope list shows exactly one next item. The finish line is always visible.

When you finish all tasks:

• Kanban: Cards are in the "Done" column. The board looks empty. Now what?
• Shipping system: You're prompted to mark the project as shipped. It moves to your Harbor. You get a Ship Card.

When the project stalls completely:

• Kanban: The board sits open in your browser tabs for months until you quietly close it.
• Shipping system: Ship it or kill it. Killing is a deliberate decision that frees you to start something new. No silent abandonment.

When Kanban Still Works for Solo Developers

I don't want to be dogmatic about this. There are cases where a kanban board is fine for one person.

Bug tracking is one. If you have a shipped product and users are reporting bugs, a simple board with "Reported," "Fixing," and "Fixed" columns works well enough. Bugs are an ongoing stream of work with no fixed endpoint, which is exactly what kanban was designed for.

Maintenance work is another. If you're maintaining multiple projects and need to track small tasks across them, a board can help you see everything in one place. You're not trying to ship a project. You're trying to keep things running. Different goal, different tool requirements.

And if you're a visual thinker who genuinely finds it easier to process information when it's displayed spatially, a board view has value. Just don't confuse the visual format with the methodology. You can display a locked scope list as a board if you want. Just don't add the "To Do" column that accepts unlimited cards.

The Trello alternative comparison I put together goes deeper on this. Trello is fine for what it is. The problem is what people expect it to do versus what it actually does.

The Real Reason Why Kanban Fails Solo Developers

The personal kanban problems I've described all come back to one thing: Kanban is a coordination system, and solo developers have nobody to coordinate with.

When you remove the team, you remove the pull-based scheduling. When you remove multiple workers, you remove meaningful WIP limits. When you remove the ongoing stream of work, you remove the need for throughput optimization. What's left is a board with columns and cards, which is just a to-do list that takes up more screen space.

This isn't a criticism of Kanban. Kanban is an excellent system that has improved manufacturing and software development for decades. It's a criticism of applying it in a context where its mechanisms can't function. You wouldn't use a traffic light system for a single-lane road. You don't need Kanban for a single-person team.

If you've been using personal kanban and wondering why your projects still don't ship, now you understand why kanban fails solo developers. The tool you're using was designed for a problem you don't have (coordinating multiple workers) and ignores the problem you do have (locking scope, forcing completion, and getting to "shipped").

Frequently Asked Questions

Does personal kanban actually work?

For simple visual task tracking, it's fine. You can see your tasks, you can drag them around, and some people find that satisfying. But calling it "kanban" is misleading. Real Kanban involves WIP limits across a team, pull-based scheduling, and flow optimization between multiple workers. A solo dev with three columns is just using a to-do list with extra steps. If that to-do list helps you stay organized, great. Just don't expect it to solve your shipping problems.

What should solo developers use instead of kanban?

A locked scope list with binary states: not started and done. No "in progress" column needed when you're one person. You already know what you're working on. Define 5 to 7 items that must be done for v1 to ship. Lock the list. Work through it. When every item is done, the project ships. New ideas go on a v1.1 list. This approach forces completion in a way that kanban boards never will.

Is a kanban board useless for one person?

Not useless, just oversold. If you like seeing tasks visually, use a board. But don't pretend it's a methodology. It won't stop scope creep, it won't enforce completion, and it won't tell you what to work on next. A kanban board for one person is a visual preference, not a productivity system. The danger is thinking you've solved your project management problem by setting up a board when you've actually just made your to-do list prettier.

Why do so many developers use kanban for personal projects?

Because Trello made it the default. Create a board, get three columns, start dragging cards. It feels productive. The drag-and-drop interaction is genuinely satisfying, and seeing cards move from left to right gives you a sense of progress. But feeling productive and actually shipping are different things. Trello's success has more to do with its UI design than with kanban's effectiveness for solo work.

---

Your kanban board isn't a system. It's a comfort blanket. If you want to actually ship, try a locked scope with binary task states. Get started with FoundStep and finish your next project instead of organizing it.