What Laver is

It is opinionated and small on purpose. The board is the default and the important view, a ticket's shape is decided once per board rather than negotiated per ticket, and there is one place each for people, billing, and documentation.

The problem it solves#

Most teams end up with work in one tool, decisions in another, and no reliable answer to "what is everyone on right now". Laver keeps the board and the reference material in the same workspace, under the same membership list, so that access is decided once and both halves stay in step.

It is a good fit when the answer to "who is doing what" changes daily and needs to be visible without asking. It is not a substitute for a spreadsheet, a document editor, or a full project-planning suite.

The objects you work with#

• Workspace — the tenant, and the boundary for people, billing, and everything inside it. Every user in a workspace holds one role — owner, admin, member, viewer, commenter, or one of the two guest roles. See Roles and permissions.
• Board — one kanban board inside a workspace, with its own columns and its own access list.
• Status column — a column on a board, such as Backlog. Columns belong to a single board and set the order of the workflow. One column per board is marked as the completion column.
• Ticket — a card on a board. It carries a title, a rich-text description, assignees, labels, a priority, a start and due date, a checklist of subtasks, comments, attachments, links to other tickets, any custom fields its board defines, and a history of what changed.
• Automation rule — a rule on a board that watches for something happening and does something about it, built from a trigger, optional conditions and actions.
• Wiki — a tree of pages belonging to the workspace, with page history and attachments. Pages can be visible to the workspace or private and shared with individual workspace members.
• Sprint — an optional setting on a board that turns it into a repeating series. At the end of each sprint Laver creates the next board with the same columns, carries the unfinished tickets over, and leaves the finished ones behind on the old board.

The containment is strict: a workspace holds boards, a board holds columns and tickets, and nothing is shared between workspaces. See Workspaces and boards.

Who it is for#

Teams of roughly three to thirty people who want a shared board without configuring one. Laver assumes everyone with a login is a colleague: access is granted per workspace and per board.

It also suits teams who want their tooling to write to the board. Every action in the app is an API call, and workspace-scoped API keys let scripts and agents create and move tickets — see the API quickstart. An MCP server puts the same boards in front of Claude, Cursor or any other MCP client without writing a client at all.

What Laver does not do#

Said plainly, so you do not go looking:

• The board is the default view, and nearly the only one. There is no list view, no calendar and no grooming view.
• Custom fields are per board, not per workspace.
• No estimates or time tracking. There is nowhere to record points or hours.
• Reporting is measured, never estimated.
• Automations are per board, and a closed vocabulary.
• Import is a file, not a connection.
• Sharing outside the workspace is deliberate and narrow.
• The free plan is the starting point, not a locked workspace.

Where to go next#

• Quickstart — a working board in about five minutes.
• Your first workspace — what a new workspace comes with.
• Roles and permissions — who can do what.