The Case for the Constrained Kanban

Every project management tool promises flexibility. Custom columns! Custom workflows! Make it your own! And every team eventually discovers that flexibility is a trap.

At CodeBake, we made a different choice. You get four columns: To Do, In Progress, Review, and Blocked. You can't add more. You can't rename them. You can't create sub-statuses or custom fields. And that's the feature.

How Customization Becomes Complexity

I've watched this pattern unfold dozens of times. A team starts with a simple kanban board. To Do, In Progress, Done. Clean and clear.

Then someone suggests a "Review" column. Makes sense — you want to know what's waiting for code review versus what's actively being worked on. So far, so good.

But then an engineer needs to ask a stakeholder a question before they can continue. Where does that task go? It's not really "In Progress" if it's waiting for an answer. Someone proposes a "Questions" column. Now you have five columns.

Then the frontend and backend work starts getting confused. "To Do Frontend" and "To Do Backend" columns appear. Seven columns.

Then QA wants visibility, so "Ready for QA" and "In QA" columns get added. Nine columns.

Before long, your weekly standup is a 45-minute slog through a board that nobody fully understands. The tool that was supposed to create clarity has created noise.

What We Left Out (On Purpose)

CodeBake doesn't have:

Custom columns. You get To Do, In Progress, Review, and Blocked. Done and Cancelled tasks disappear from the board — you're only ever looking at active work.

Priority levels. If a task is in the To Do column, it should be worked on. Top to bottom. If something is more important, move it to the top. If your AI agent asks for the next task, it gets the first one in the column. No P1/P2/P3 debates, no priority matrices, no "high priority" tasks that sit untouched for weeks.

Story points or estimation. We've never seen a team where story point debates improved the actual work. They just create a new category of meetings.

Sub-statuses. A task is either in progress or it isn't. If it's blocked, move it to Blocked and say why.

Each of these missing features is a decision to keep things simple — even when "simple" feels limiting at first.

Solving Problems Without Adding Columns

The "Questions" column problem from earlier? Here's how CodeBake handles it:

Move the task to Blocked. Add a note explaining what you're waiting on. Assign it to the person who can unblock you. When they've answered, they move it back to In Progress and reassign it to you.

No new column. No new workflow. The Blocked column does exactly what it says — it shows work that can't move forward until someone else acts. That someone might be a stakeholder answering a question, a designer providing assets, or a teammate finishing a dependency. One column handles all of it.

Phases: Scope Without Complexity

CodeBake does have one structural concept beyond the basic kanban: phases.

A phase is simply a separate list of tasks. Your team can only work on one phase at a time. When you complete a phase, you move on to the next one.

This solves the backlog problem. Ideas for future work, features you're not ready to build yet, technical debt you'll get to someday — all of that lives in a future phase, not cluttering your current board.

If your team wants to use sprints, you can rename phases to "Sprint 1," "Sprint 2," and so on. But you don't have to adopt the full sprint ceremony to get the benefit of scoped work.

Why Constraints Work

The argument for flexibility sounds reasonable: every team is different, so let teams build what works for them. But in practice, "what works" usually means "what someone thought would work six months ago" — and now the team is stuck maintaining a system that's harder to change than the code itself.

Constraints force simplicity. When you can't add a "Questions" column, you discover that Blocked already handles it. When you can't set priority levels, you discover that column order is enough. When you can't create sub-statuses, you discover that most of them were unnecessary distinctions anyway.

The best project management system is one that fades into the background. You shouldn't be thinking about your kanban board — you should be thinking about your work. A board with four columns is easy to understand at a glance. A board with nine columns and custom statuses requires meetings just to explain itself.

Less Board, More Building

CodeBake was built for teams that want to ship software, not maintain elaborate project tracking systems. Four columns. Top-to-bottom priority. Phases for scope. That's it.

If you've ever spent more time debating your workflow than doing the work itself, you know why this matters.

‍