How to Build a Kanban Board Without Code, Step by Step

To build a kanban board without code, name your columns, list the fields a card carries, and say what dragging a card between columns should do. Connect Supabase so the board survives a page refresh, then let the builder generate it. A single-board build costs 6 credits and takes about a minute.

The obvious question first: Trello, Linear, and Notion exist and are good. Building your own only makes sense in a narrow set of cases, and the honest version of this guide starts by naming them rather than pretending the general tools are bad.

When is a custom kanban board better than an existing tool?

When the card is not a task. Teams that track applicants, deliveries, service jobs, content pieces, or equipment repairs end up bending a task tool into a shape it resists, and every workaround field costs a little attention forever.

When the board has to be embedded. A production board inside your own admin panel, next to your own data, with your own logins, is a different product from a board in someone else's tab. Embedding is where generated tools quietly win.

And when the board is for people outside your team. A client-facing board showing only their projects, with your branding and nothing else visible, is awkward to build on a general tool and straightforward to describe in a prompt. For an ordinary internal to-do list, use Trello and spend your evening elsewhere.

What should you decide before you build?

Four decisions, and writing them down is most of the work.

• The columns. Name them as your process, not as a template. "Intake, Quoted, Scheduled, In progress, Invoiced" beats "To do, Doing, Done" if that is what actually happens.
• The card. Title plus the four or five fields you genuinely look at: owner, due date, value, client, priority. Everything else belongs on the card detail view, not the card face.
• What a move means. Dragging into "Invoiced" might just change a status, or it might stamp a date, or it might send an email. Say which.
• Who sees what. One shared board, a board per person, or a board per client. This decision shapes the whole build and is expensive to change later.

The move rule is the one people forget. A board where dragging a card only changes its column is a picture of work. A board where dragging into "Scheduled" also stamps a date and notifies the owner is a tool that saves someone a step every day.

What should the build prompt say?

Build a kanban board app for [team / process].
Login through Supabase; [everyone sees one shared board / each user
sees only their own cards / each client sees only their board].
Columns, in order: [your five or six columns].
Card face shows: title, owner, due date, [one more field].
Card detail: description, checklist, comments, attachments,
history of column changes.
Dragging a card to a new column updates its status and stamps
the date of the move.
Moving into [column] sets [field] and sends an email to the owner.
Board view: columns side by side, card count and total [value] per
column, filter by owner and by [field], search by title.
Also a list view of the same cards, sortable by due date.
Overdue cards are visually marked. Dates as YYYY-MM-DD.
Currency in US dollars.

Ask for the list view in the same prompt. Every kanban board eventually needs a flat sortable table, because "what is overdue across all columns" is a question the board layout answers badly, and adding it later costs an extra edit for no reason.

What does a kanban board cost to build?

A single board is one page. Add a card detail view, a list view and an admin screen, and it becomes a platform build instead, which is priced at 12 credits for the first three screens and 3 for each one after.

Free comes with 5 credits, less than a single page, so it is a look around rather than a launch plan. Pro is $25 per month for 200 credits, which is roughly 66 edits if all you do is iterate. Business is $99 per month. See the pricing guide.

How do you make the board remember anything?

Connect Supabase. Without a database the board is a page: it looks right, it drags correctly, and everything resets when someone refreshes. That is fine for a prototype you are showing to a colleague and useless for anything you rely on.

With Supabase the app gets a real Postgres database plus authentication under your own account. Cards, columns, and the history of moves live in tables you can query, back up, and export with ordinary SQL, which also means the board's data is never trapped inside the builder. Setup is in connecting Supabase.

Decide permissions deliberately before real work goes on the board. Who can move a card, who can delete one, and whether a client can see other clients' cards are three questions with three explicit answers. Then verify by logging in as a second user and trying the move that should be blocked.

How do you stop the board becoming a graveyard?

Two rules, and both are lines in the prompt rather than habits somebody has to remember. Cap how many cards each in-progress column may hold and show the count in the column header, so a column over its limit is visible without anyone counting. A column holding nineteen cards is a list, not a process.

The second rule is an archive. Cards that reach the final column stay visible for a week, then move to a searchable archive view. Without that the last column grows until the board needs a scroll to read, and people quietly stop opening it. Ask for both in the first build: "Each in-progress column has a card limit and turns red above it. Cards sit in the final column for seven days, then move to an archive view."

Then give the board a monthly review slot. Open the archive and the oldest card in each column together, because a card nobody has touched in six weeks is finished, cancelled, or hiding a decision nobody wants to make. All three outcomes are useful; leaving the card where it sits is not.

What are the honest limits of a generated board?

• Live multi-user sync. Two people watching the same board and seeing each other's drags in real time is a specific piece of engineering. Do not assume one prompt delivers it, and test with two browsers before you promise it to a team.
• Deep integrations. Cards created from your issue tracker or your inbox are API work. The builder makes the board; export the code to GitHub and have a developer wire the pipe.
• Complex automation rules. Multi-step conditional workflows, SLA timers, recurring cards. Reachable through repeated edits, not one paragraph.
• A replacement for your engineering team. On a product your company sells, this is a fast path to a working internal tool, not a substitute for people who own it long term.

Before a build reaches you it is booted in a sandbox, so a board that fails to render is reported as a failure rather than handed over blank. That lowers the risk of a broken publish without removing it, so drag a card yourself before inviting anyone.

What should the first version be?

One board, your real column names, five fields on the card, and Supabase connected so it persists. That is 12 credits including the card detail view. Run your actual work through it for a week with the two or three people who will use it.

The week will tell you which field nobody fills in and which one is missing. Then edit at 3 credits a change. If the board is really a sales pipeline, the fuller build is in how to build a CRM; if it tracks stock rather than work, see an inventory app. Start at zugo.dev.