The Best Free Kanban Board Options, Compared Honestly

A free kanban board is enough when you need to see work, cap what is in progress, and pull cards from left to right. It is the wrong tool when the real failure is intake: Slack threads, call notes and production errors that never become a card. Below are options you can start without a contract, and where each one runs thin for a software team.

How to choose a free kanban board without a bake-off

People searching for the best free kanban board want a winner, and there isn't one. The board that works is the one sitting next to the system your team already updates. GitHub issues copied onto a second board turn into a second inbox, and a client request that stays in chat never fills the Ready column.

Check five things before you move anyone:

• The card is the unit of work you ship, or it links to that unit.
• You can cap the columns that clog, and the tool shows when the cap breaks.
• A teammate who did not create the board can move a card.
• History keeps who moved it, when, and from which column.
• The free plan still works once the whole team is on it, including people other than whoever set it up.

A tool that fails the last check is a trial with a countdown. Atlassian's kanban overview states the board, the limit and the pull rule, and every tool below can draw that picture. If the columns themselves are still fuzzy, read what a kanban board is for first.

Run the five checks on one real week of work instead of a feature grid. Take last Monday's requests and ask where each one would live. If three of them have no home, the tool isn't your problem yet. Write the column names on paper before you create them in the product. If you can't say a column name out loud in standup ("In progress / blocked / waiting on design / almost"), it's probably two columns sharing one label.

Most teams score tools on charts, automations and mobile apps. Those matter only after the card means the same thing to the engineer and the founder. Teams also start with ten columns because a blog post showed ten. Four columns you actually move cards through will do more for you than a diagram of a process you don't run. Invite one person who did not set the board up and ask them to move one card. If they can't, the free plan has failed before you even have a process.

Five options that are actually free to start

Trello

Trello is the tool most people picture. Lists are columns, cards are work, and a new teammate learns it in one sitting. A content calendar, a hiring pipeline or a small ops queue can live here for a long time.

A software team runs into the edges quickly. A card is not a pull request, and a checklist is not a definition of done the repository knows about. Power-Ups imitate a workflow, and the free plan keeps them on a short leash, so the board can look calm while the repo says otherwise. That split is covered in Trello kanban boards for development teams.

Use Trello when the board is the system of record. Leave it when GitHub, GitLab or a ticket tracker already plays that part.

If Trello really is the system of record, start with four lists: Inbox, Ready, Doing, Done. Inbox is unsorted. Ready is what you have agreed to pull from, and it's capped. Doing is capped at one or two cards per person. Done is dated by the week and then archived, so the list doesn't turn into a trophy case. Each card gets one owner, a one-line outcome, and a link to the spec or the file if one exists. Hold off on labels until the lists are moving, because labels multiply when the lists are wrong.

Avoid a card template with twelve custom fields on day one. People leave the title blank and standup turns into a reading of dropdowns. Title the card the way you would say it: "Send the March invoice to Northwind," not "Ops / finance / March." A card that is "waiting on the client" doesn't stay in Doing. Give waiting its own column, or a label you review on a fixed day, or the cap stops meaning anything.

GitHub Projects

GitHub Projects is the free kanban board that fits when the work is already an issue or a pull request. You get a board and a table over the repositories you choose, and status is a field you define. One board can be filtered down to bugs, this milestone, or a single assignee without cloning cards.

The cost is the shape of GitHub. A founder, a support lead or a client will not file a clean issue, and you shouldn't ask them to. There is also no client record beside the card. If engineers already triage in issues, start here before you add a second product.

Set the status field to the columns you will say in standup, and hide the views you won't use. A good first layout is a board for Ready, In progress, In review and Done, plus a table grouped by assignee for whoever runs triage. The table is where you notice that one person has six cards in progress and another has none. The board is where you pull.

Write the issue so the card can stand alone. "Fix login" is not a card. "Login returns 500 when the email has a plus sign, and the test in auth.spec covers it" is a card.

A common trap is one project per repository when the team ships across three repos, which leaves people hunting for the card. Make one project that pulls issues from those repos, filtered to the current milestone, and treat that as the board. Extra views for "my items" are fine. Also keep the project from becoming a scratch pad for ideas that aren't issues yet, since a draft looks like work. Keep drafts out, or put them in a status you never count as Ready.

Jira

Jira's free plan suits a small team that wants statuses tied to columns, a backlog, and reports that go further than a card count. It also annoys people faster than anything else here when every scheme, screen and required field is switched on.

Keep it dull: one workflow, a few statuses, a WIP limit on In Progress, and a definition of done on the board. Setup, and the point where Jira gets too heavy, are in how to set up a Jira kanban board.

Pick Jira when you need a backlog and permissions more than a friendly first card. Leave it when configuration has become a part-time job and you still ship from one repo.

Start from the template with the fewest statuses you can stand, then delete the rest. To Do, In Progress, In Review, Done is enough for a first month. Map each status to one column and turn on the WIP limit for In Progress only. Put the definition of done in the board description: merged, deployed, and the reporter told, or whatever "done" means for you.

Where Jira goes wrong is a required field for every department that might someday care. A production bug then takes ten minutes to file, so people file it in Slack instead. If a field is empty on half the cards, it isn't really required. "Waiting on QA" and "waiting on legal" are reasons for being blocked, so one Blocked column with the reason written on the card covers both. Six separate blocked statuses just hide the fact that the work is stuck.

Notion

Notion will show any database as a board. That's why teams adopt it, and it's also why engineering boards rot there. A status field is not a workflow, and nothing pushes back when In Progress grows. The view that counts ends up being whichever filter its author remembers. The links to specs are worth keeping; the board as a delivery system is not.

If the engineering space is mostly notes, a light board next to those notes is fair. If you need a column to mean the same thing every week, read what you give up with a Notion kanban board before you move the team.

If you still use it, make one database, one status property, and one board view named "Board," and pin that view. A card links to the spec page instead of copying the spec into its body, where the two would drift apart.

Watch for statuses added in the moment: "Paused," "Later," "Maybe Q3." After a month nobody can tell Ready from Later. Freeze the list, and treat adding a status as a team decision made out loud. Linked views on meeting pages cause the other problem. People drag cards around in them, and the filter hides those cards from the real board. A meeting page should link to the card rather than host a second board.

A board you host yourself

Kanboard and similar open-source trackers have free licenses. You pay instead with a server, upgrades, backups and a login lesson for every new hire. That trade is reasonable when work cannot sit on someone else's cloud.

It's a bad trade when "free" really meant "nobody owns this." Someone owns the database file, the certificate and the password reset, so name that person before you install it.

Before you install, write down where the backup lands, who can restore it, and what happens when that person is away. A board you can't restore is a notebook you can lose to one disk failure. Put upgrades on a calendar. Teams often install it on a laptop "for now" and then invite everyone. The laptop sleeps, the board disappears, and people go back to chat. Run it on a machine the team can reach on a normal day, with a named owner.

A table you can paste into a decision doc

Tool	Free plan fits when	It fails when
Trello	The board is the list, and the work is not code	The card must be the issue, the pull request or the incident
GitHub Projects	Issues and pull requests are already the queue	Non-engineers must file and track the same work
Jira	You want statuses, a backlog and basic reports	Admin work outgrows the team
Notion	The board sits beside docs and notes	You need limits, history and a stable workflow
Self-hosted	The data must stay on a machine you control	Nobody is named to patch and restore it

The table is not a ranking. One company can run hiring on Trello and bugs on GitHub Projects and be right both times.

Paste it into the decision doc with one sentence under the row you picked: who owns the board, and which system is not allowed to become a second copy. Without that sentence the table is a menu, and the team will order two.

Worked example: a six-person team with two queues

Picture four engineers, one designer and one founder, with two kinds of work arriving each week. The caps below illustrate the rules; they are not a benchmark.

Queue A is bugs and small features, and they already exist as GitHub issues. Copying them onto Trello means typing every bug twice, and the copy goes stale the day a pull request merges.

Queue B is founder-led: a customer call, a partnership, a "can we just" from an investor. None of that starts as an issue. It starts as a sentence. If the rule is "no card, no work," the founder needs a tray that an engineer can later turn into an issue.

A setup that respects both:

• GitHub Projects holds Queue A, with columns Ready, In progress, In review and Done. Ready is capped at 8 cards. In progress is capped at 2 per engineer, so 8 for this team. A ninth card means someone has to talk about it instead of letting the column overflow.
• Trello holds Queue B, with lists Inbox, Promised, Doing and Handed to engineering. The only way out of Promised is a GitHub issue link on the card. The founder spends 20 minutes each Monday on Inbox and deletes what they will not do.
• Once a week, the engineer on triage turns Promised cards into issues, then moves the Trello card. A card without an issue does not move. That one rule is all the integration you need.

Here is one Monday under those rules. The founder opens Inbox and finds eleven cards. Four are the same request, written three ways, so they merge them into one card, move it to Promised, and title it with the outcome: "Export the last 90 days of invoices as CSV." Three cards are ideas with no customer, and those get deleted rather than parked on a Someday list, which is where "no" goes to hide. Two cards are questions, not builds; the founder answers them and archives the cards. The last two were promised on a call. They go to Promised with the call date on the card.

On Tuesday the triage engineer opens Promised, not Inbox. The CSV export becomes an issue with a done line: a button on the billing page, a file the customer can open, and a note in the thread when it ships. They paste the issue link on the Trello card and move it to Handed to engineering. The other promised card is too vague, so they comment "need the field list" and leave it. It doesn't become an issue just to be polite.

Ready on the GitHub board already has eight cards, so the new issue waits until something leaves Ready. If the founder needs it this week, something else in Ready goes back to the backlog in the same conversation.

Watch two counts, even on free tools: how many cards sit in In progress longer than five working days, and how many Inbox cards are older than two weeks. Those numbers tell you whether you have a kanban flow or a parking lot.

You can count them by reading the cards; you don't need to buy a report. Open In progress, look at the date each card entered, and write the two numbers at the top of the standup notes. If In progress has cards older than five working days, standup covers those cards and nothing else. If Inbox has anything older than two weeks, the founder deletes it or promotes it before anyone discusses new work.

Don't treat the two boards as peers. Queue A is the delivery system and Queue B is intake. The week someone reports status from the Trello board, the same work gets counted twice.

The triage engineer will be tempted to do a Promised card themselves because filing an issue feels slow. Then Queue B grows a secret Doing column, and the GitHub cap never sees the work. Filing the issue is the job; doing the work is a pull from Ready. Side chats are the third leak. If a sentence matters, the person who heard it writes the Inbox card during that conversation.

What a kanban tool free of money still costs

A kanban tool free to create is rarely free to operate. You pay in hours.

You get double entry when the board is not the issue tracker. Someone stops updating one of the two, and it's always the one managers read.

You get a Done column that means "someone dragged it" rather than "it shipped." If the merge finishes the work, the column should follow the merge.

You get one admin who knows which filter is the real board, while everyone else argues from a screenshot of the wrong view.

And you get no forecast. A count of cards in Doing doesn't tell you whether the next ten will finish this month. That guess needs the time each card spent in each column, and most free boards store the current column and drop the path. You can have a tidy board and a missed date in the same week, because inventory and throughput are different questions.

Seat rules matter as much as feature limits. An online kanban board free for the person who created it often charges for observers, or hides the board in a workspace a client will never open. The client then asks again by email, and the board drifts away from the thread where the work actually gets decided.

Budget a weekly half hour that is separate from standup. One person checks the cap, the aging cards, the cards with no owner, and the titles that no longer match the work, and fixes those before anyone adds a card. Skip it and the board becomes a mural: people still drag cards, but the picture stops matching the work.

The cost you notice last is someone leaving. The person who created the workspace owns the billing email, the export, and the only map of which automation matters. Write down the login owner and the export steps next to the column rules while they're still on the team. If a card has a date, write it on the card. An average of finished cards kept on a notepad is more honest than a chart the free plan can't build, though a week of tiny bugs and a week of one migration still aren't the same throughput.

When the board is not the bottleneck

Some teams outgrow a board while it still looks fine. Requests stay in Slack. A call produces notes and no owner. A production error gets a reaction and no ticket. The columns are empty because the work never entered.

Another free board won't fix that. You need one intake door, triaged daily, and a rule that work without an owner does not start. The board can only show what came through that door.

Name the door: one channel, one inbox, or one list, described in a single line such as "If it is not in Inbox by 4 p.m., it is not in tomorrow's triage." When work shows up somewhere else, reply with the link and the sentence to paste, so there's never a second door.

Triage takes fifteen minutes at the same time each day, with one person on a rotation. Each item is deleted, answered, filed on the delivery board, or left with a date for deciding. "Leave it" with no date is just a second parking lot. If the same person always triages, the door closes when they're away.

A reaction emoji on a production error is not an owner. The person on call writes one card with the error, the time, and whether a customer saw it, then goes back to the incident. A thin card is enough, and the next day triage promotes it or marks it done. Founder calls need a line on the checklist too: before the call ends, the request is either a card or explicitly not happening. Nobody's memory counts as a column.

Falrow is the heavier version of that idea, built for teams whose requests already arrive as Slack messages, call notes and Sentry errors. Those become tickets, and the board is a view of the tickets. Stages and triage sit on issues and workflow rules, and the path from request to shipped work is the delivery loop. Falrow is in private beta with pricing on request, so it is not a free-plan contender. It fits once you've decided a board was never the missing piece.

Switching tools at that point feels like progress, but it repeats the empty columns on a new domain. Spend two weeks on the door you have. If cards arrive and the columns still lie, look at a system that makes the ticket from the message. If cards don't arrive, a new board will sit empty too.

First month on a free kanban board

Week one is the columns, the cap, and real work. Delete every test card at the end of the week, because test cards teach people the board is fake.

Week two, send aging Doing cards back to Ready or finish them. Don't add a column called Stuck; a stuck card needs a conversation, not a place to sit.

Week three, if you have two kinds of work, run the handoff once while the other person watches. A rule nobody has seen in use gets reinvented in chat.

Week four, ask which column lied, which card had no owner, and which request never became a card. Then change one rule.

Hold off on inviting the whole company until the people who move cards trust the board. Observers ask for a column per meeting, and the caps come off to keep everyone happy. Wait until one real card has moved from Ready to Done under the cap. Then show them the board and tell them which list they may add to.

FAQ

Is Trello still a good free kanban board?

Yes, when the card is the work. Hiring, editorial calendars and a founder's personal queue all fit. It is a weak system of record for a team that already ships through issues and pull requests, because nothing on the free plan keeps the two in step. Put the delivery board where the code is, and keep Trello for work that never becomes an issue.

Do we need WIP limits on the first day?

Yes, on one column. Cap In Progress at one or two cards per person. Cap Ready so it can't pretend to be a promise, and leave the raw backlog uncapped until people trust the board. A limit nobody acts on is worse than no limit, so when one breaks, finish a card or send it back at the next standup.

Can one board cover engineering and the rest of the company?

It can, but it usually shouldn't. Engineering cards move when code moves. Sales, hiring and support cards move when a person says so, and shared columns hide both. Two boards with a written handoff, as in the example above, stay honest. Share a single board only when every card type follows the same pull rule and the same definition of done.

Should client requests live on the same board as bugs?

Only after they are accepted. Raw requests include duplicates, questions and ideas you will never build. Keep them in a separate list, review them on a schedule, and promote the few you will do onto the delivery board as normal cards. Clients can then hear the status of accepted work without watching every rejected idea.