Every agency has tried it. You invite the client into your Trello, or your Asana, so they can "see where things are". Two weeks later they've opened it once, the cards have drifted, and you're back to writing the Friday summary by hand. A freelancer put it plainly on r/freelance: you can absolutely give clients visibility in Asana, "however, it is very difficult to get other people to voluntarily use the software."
I run SharpHaw, a small agency in Lisbon, and Boards is the row of our replacement ledger that stands in for Trello and Asana. This is part of a series that takes that ledger one surface at a time. This post is about what a kanban board has to become when the client is meant to read the same one you work from, and where Trello is still the right answer.
TL;DR: we didn't build a prettier kanban. We built a per-organisation database with columns on top, because a client-readable board needs three things a personal one never does: visibility per card, a paging contract that never hides a matching card, and a write path humans and machines share.
What Trello and Asana are for, and where they strain with clients
Trello is the fastest way I know to get a team moving cards. Asana is the grown-up version with dependencies, portfolios and a timeline. Both are excellent at the job they were designed for: a team organising its own work.
They strain at the exact point an agency needs them most. The board is in your account, so the client is a guest in a tool they didn't choose, with a login they'll forget. Everything on the board is equally visible, so the notes you'd rather keep internal live in a second board, and now there are two boards to keep honest. And the board knows nothing about the rest of the engagement: the brief is in a document somewhere, the assets are in a drive, the lead the card produced is in a CRM. A small-business owner asked on r/smallbusiness for a way for clients to "physically see things moving along (like a dominos pizza haha)". That's the whole requirement, and a guest seat on a task tool doesn't meet it.
What Boards does instead
In SharpOS every client is an organisation, and a board lives inside it. The client isn't a guest; they're a member, with the role they were given: owner, manager, editor or viewer. There's nothing to invite them into, because the board is already in the workspace they log into for everything else.
A card is more than a title with a checklist. It carries assignees, a due date, rich content in the same collaborative editor Pages uses, an optional linked page, and custom properties: text, numbers, dates, money, members, images, relations to other cards, customers, pages or Studio frames. The same cards render as Columns, Table, Grid or Calendar through saved views, with a filter builder and sort that every reader can switch between and editors can save.
Two things matter more than the layouts. First, visibility. Every board and every card is either client (every member can read it) or internal (platform admins only). An owner can't flip it; only SharpHaw staff can. Switch a board to internal and every active card on it goes internal with it, and an internal deep link returns not found to anyone who can't read it. That is how the "second board for our notes" problem disappears: the notes live on the same board, one lock icon away.
Second, the board is where the work is. This article is a card on our Dev.to board, created from a Dev.to template that ships with the product, and it moved Review → Approved → Published the same way part one did. A column can be pinned to the organisation's home screen ("Show on home"), so the client's landing page is literally the queue we're working from this week. Seventeen templates ship today, from a plain kanban to client onboarding, audit remediation and one board per publishing network.
You can open a board yourself, no account needed: the SUMI showcase workspace runs the real board components against fixtures in your browser. The feature page is at sharphaw.digital/features/boards.
How it works
Three decisions carry the surface.
A board is a database first. Underneath, boards, columns, cards, views, grid order, property definitions, property values and external source links are all separate records rather than one big document. It is more structure than a checklist needs, and it's what makes drag-and-drop, the filter builder, saved views, the REST and MCP surface and the shared editor possible without collapsing a board into a page.
Big boards load in pages, but never hide a matching card. A board opens with the first 25 cards of each column and grows in place, under a board-wide budget of a thousand cards, so a board bigger than one load can serve still opens with a usable view instead of failing. The catch is sorting, filtering and searching: ordering over a partially loaded column would silently hide cards that match. So any of those actions loads the column to its ceiling of 500 before it answers, and the page sizes live in one shared definition so the backend and every client agree on them.
One write path for people and machines. Every board, column, view, card and property action is defined once; the REST routes and the MCP tools are two doors onto the same definitions, so they inherit the org boundary, the feature flag and the visibility hierarchy. A small example of why that matters: an organisation may watch at most eight columns on its home screen, and the cap is enforced where the write happens rather than only in the UI, because the REST and MCP paths reach the same write. An agent moving cards gets the same rules as a person dragging them.
What it doesn't do
Boards is shallower than Trello and Asana in ways I'd rather say out loud.
There are no dependencies between cards and no timeline of the Asana kind; if your work is a critical path, keep Asana. The filter builder covers select, multi-select, checkbox, members and status, so you can't yet filter on a date range or a number. Table column widths are saved per browser, not per view. There are no Power-Up-style plugins; the extension surface is the API, the MCP server and Automations, which is great if you write code and irrelevant if you don't. Publishing a board into a Framer CMS collection exists, but it's manual and platform-admin only. And there is no CRM template on purpose: pipelines over people and companies belong to Customers, not to a board.
If the board is for a team organising its own work, Trello is still the right call and I'd pick it myself. Boards earns its place when the person reading the board is the person paying for the work.
Where it sits in the SharpHaw service
Every SharpHaw engagement runs as a weekly queue on a board: the Content Engine's editorial boards, the website's change queue, the audit findings tracked to done. That's the part of the subscription the client reads most, which is why it had to be the part the client can trust. The service pages are at sharphaw.com/services/content-engine and the workspace itself at sharphaw.com/sharp-os.
A question for people who've tried the guest-seat approach: what finally got a client to actually open the board, and how long did it last?
This is part of SharpOS, surface by surface. Part 1, the ledger and the row we couldn't replace: We replaced a 12-tool client stack with one workspace we built.
Top comments (0)