Why kanban sounds great but does not scale for workflows

The request comes up constantly. In 2018, a customer from a hospitality software company asked us directly:

A Kanban Board… If each step of the blueprint could be assigned to a tag.

We have heard this request dozens of times since. The visual appeal is obvious - cards moving across columns feels satisfying. Trello built a billion-dollar company on that satisfaction.

But here is what I wrote to the team in May 2019, after years of watching this pattern:

I suggest closing this view for now, as it is not as scalable or dense as the table view.

That was a hard decision. Kanban views are sexy in demos. They photograph well for marketing. Prospects instantly understand them. Closing that feature request felt like leaving money on the table.

It was the right call.

The density problem

In April 2018, I laid out the core argument in a Basecamp discussion:

The thing about spreadsheet/table/grid view is that it does both presentation and editability in one shot.

This is the fundamental difference. I expanded on this in another thread:

Tables are info-dense and people are familiar with spreadsheets (hence the success of smartsheets.com) - so this should play much better for serious customers than card-like views e.g. Trello.

The Smartsheet reference was not casual. They built a massive business on the insight that serious operations people think in rows and columns, not cards and columns. A kanban card shows you a summary. Want to edit something? Click the card. Wait for the modal. Find the field. Make your change. Close the modal. Now multiply that by 50 tasks.

A table cell? Click it. Type. Done.

Our CTO articulated this even more clearly:

I think that a kanban board format is interesting, but I am more interested in: 1. Further refining the Tasks page. 2. Creating a run view with high data density.

High data density. That phrase captures everything.

When you are managing real workflows - not a personal to-do list, but actual business processes with deadlines, assignees, form data, and status indicators - you need to see a lot of information at once. Kanban sacrifices density for visual appeal.

The column explosion

Here is a practical problem nobody talks about in kanban demos.

A simple kanban board has three columns: To Do, In Progress, Done. Beautiful.

A real workflow might have: Not Started, In Progress, Waiting for Input, Under Review, Pending Approval, Approved, Needs Revision, Blocked, On Hold, Completed, Cancelled, Archived.

That is twelve columns. On a laptop screen. Good luck dragging cards across that without horizontal scrolling.

And that is just one process type. What happens when your operations team tracks employee onboarding, vendor approvals, customer complaints, and equipment requests? Four separate kanban boards? Constant tab switching?

The column problem gets worse when you consider what information lives on each card. In one discussion about what a grid view should show, the requirements kept growing:

Showing: Active, Archived. Section Name. Step title A. Step title B.

Simple enough. But then add status indicators, assignee avatars, deadline warnings, problem flags. Each cell becomes a mini-dashboard. Kanban cards cannot handle this density without becoming cluttered messes.

The Trello graduation pattern

Pravina, who handled many of our early conversations, noticed something interesting:

Most of our users have been using these [Trello, Dapulse] for a long time and look to transition to a BPM (Tallyfy) as they scale.

Read that carefully. Users transition FROM kanban tools TO workflow management. Not the other way around.

This is the natural progression. A team starts small. Five people, simple tasks, Trello works fine. The business grows. Suddenly they need:

• Conditional logic (if this approval fails, go back to step 3)
• Form fields attached to tasks
• Deadline calculations based on previous step completion
• Audit trails for compliance
• Multiple people working the same process type simultaneously

Kanban was never designed for this. It is a visualization technique borrowed from manufacturing, designed for physical cards on physical boards with physical WIP limits. The digital translation loses most of what made it work.

The lost prospect

I will be honest about this. We lost deals because we did not have kanban.

GitHub Issue #9832 documented one case:

Lost a prospect to rocketlane.com who specifically wanted Kanban functionality.

That stings. Losing business because you deliberately chose not to build a feature that prospects ask for.

But here is the thing: that prospect was looking for a task board, not workflow management. They would have churned anyway once they realized kanban does not solve the problems they actually had.

The companies that stick around are the ones who tried kanban, hit its limitations, and specifically searched for something more structured. Those are the conversations where we win.

Why DaPulse missed it

We studied competitors extensively. One assessment I wrote about DaPulse (now monday.com) captured the core issue:

Really for tasks, not groups of tasks (runs).

This distinction matters more than it sounds. A kanban board manages individual tasks. A workflow system manages groups of related tasks that form a coherent process.

In another competitor analysis, I noted the fundamental confusion:

DaPulse is really for tasks, not groups of tasks (runs). The kanban metaphor breaks when you need to track 50 instances of the same process moving through 12 steps each.

A kanban board asks: “What stage is this card in?” A workflow tracker asks: “How far along is this entire process, and which step is blocking progress?”

When you onboard a new employee, you do not have random floating tasks. You have a sequence: paperwork, then equipment setup, then training, then manager introduction. The tasks are connected. Completing one triggers the next. The whole bundle moves through the organization together.

Kanban flattens this structure. Every task becomes an independent card. The relationship between tasks disappears. The process becomes invisible.

Table views handle both cases

Here is what Walker was getting at with “high data density.” A table view works for:

Single process tracking: One row per instance of a process (like one row per employee being onboarded). Columns show each step. Cells show status. You see 30 onboardings at once without scrolling.

Multiple process tracking: Rows can be different process types. Filter by type when you need to. Or view everything your department is responsible for in one screen.

Cross-functional visibility: Managers see their team’s work. Executives see department summaries. Same interface, different filters.

Try building that flexibility into a kanban board. You cannot. The column metaphor assumes everything moves through the same stages. Real organizations do not work that way.

The editing problem

I keep coming back to this point because it matters so much in daily use. The original insight came from watching how people actually work:

The thing about spreadsheet/table/grid view is that it does both presentation and editability in one shot.

There is a reason Excel conquered the business world. Not because spreadsheets are pretty - they are not. Because the mental model of “click cell, type value” is burned into everyone’s muscle memory.

Watch someone use Trello for an hour. Count how many times they:

1. Click a card
2. Wait for it to load
3. Find the field they need
4. Make a small change
5. Close the card
6. Repeat

Now watch someone use a spreadsheet. They click a cell. They type. They press Tab. They type in the next cell. The flow never breaks.

When you are processing 50 tasks in a batch - approving expenses, reviewing applications, updating statuses - that friction compounds. Two extra clicks per task times 50 tasks times three times per day adds up to hours lost weekly.

When kanban actually works

I am not saying kanban is useless. It works well for:

• Personal task management (limited number of items)
• Software development sprints (well-defined stages, one team, one board)
• Physical manufacturing (where it was invented)
• Simple project tracking (less than 20 active items)

The common thread? Limited scale, simple states, single-process focus.

The moment you add complexity - multiple simultaneous processes, conditional logic, form data, compliance requirements - kanban becomes a liability instead of an asset.

What we built instead

The tracker view in Tallyfy ended up looking nothing like kanban. Walker summarized the priority clearly:

I am more interested in: 1. Further refining the Tasks page. 2. Creating a run view with high data density.

High data density won. The tracker is closer to a spreadsheet with workflow superpowers.

Rows are process instances. Columns can be steps, or they can be data fields, or both. Cells show status indicators that update in real-time. Click a cell to see details or make edits. Filter, sort, group - all the spreadsheet operations people already know.

One key design decision: steps that get added dynamically (through automation or manual additions mid-process) show up as new columns. Steps hidden by conditional rules show as grayed-out cells. The whiteboard sketch captured this:

Steps added later. Hidden due to rule. Expand when clicked.

Try representing that in a kanban column. Where does a dynamically-added step go? How do you show that a step was skipped because a rule fired?

The interface is not as photogenic as a kanban board. It does not demo as cleanly in a 30-second video. But the teams who use it daily - the ones managing 500 active processes across 12 different workflow types - they would never go back to cards.

The request still comes

People still ask for kanban. The visual appeal is undeniable. The familiarity is powerful.

We say no. Not because we cannot build it - the engineering is straightforward. We say no because it would make the product worse for the people who need it most.

Some decisions in product development are about what you will not build. This is one of them. The teams who need kanban have plenty of options. The teams who have outgrown kanban - those are the ones we are building for.

To that customer from the hospitality software company, if you are reading this years later, I hope you found what you were looking for. And I hope, eventually, you discovered why your workflows needed something more.