Laver docs
Open Laver
Start here

What Laver is#

Laver is hosted project management for small teams. Work lives on kanban boards as tickets that move left to right through status columns, and the long-lived writing that surrounds that work lives in a wiki next to it.

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. See Automations.
  • 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. Wiki pages can be visible to the whole workspace or private; a private page can grant individual workspace members View, Comment, or Edit access — Comment lets somebody discuss a line or a word of the page without changing it. Nothing is readable without a login until somebody publishes it on purpose — a board as a read-only roadmap, a single wiki page, or a feedback form that anyone can file a ticket through.

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. A timeline off the board header draws the tickets that carry dates, as bars you can drag to reschedule, and Split view puts two boards side by side. There is no list view, no calendar and no grooming view.
  • Custom fields are per board, not per workspace. Beyond the fields listed above, a board can define its own — text, number, date, checkbox, select or currency. They belong to that board and appear on no other, so a ticket's shape is still decided once per board rather than negotiated per ticket.
  • No estimates or time tracking. There is nowhere to record points or hours.
  • Reporting is measured, never estimated. Board stats show tickets by stage, by label and arriving per week, and — from the column history — cycle time, throughput, how old the open work is and where it is queueing. See Stats. There is no burndown, no velocity and nothing else derived from estimates, because there are no estimates.
  • Automations are per board, and a closed vocabulary. A rule is a trigger, optional conditions and up to a fixed number of actions, chosen from lists Laver defines — not a scripting language. Anything outside those lists is a job for an API key or a webhook. See Automations.
  • Import is a file, not a connection. A board can be created from a Trello, Jira, ClickUp or Microsoft Planner export — JSON for Trello, Jira and ClickUp, CSV for Jira, ClickUp and Planner. A Spreadsheet of your own imports too: any CSV, into a board you already have, by mapping its columns onto the fields yourself. Nothing syncs; see Importing.
  • Sharing outside the workspace is deliberate and narrow. By default every page and board needs a login and workspace membership. On the paid plan you can publish a single wiki page to a public read-only link, publish a board as a read-only roadmap — its columns and its ticket titles, and nothing else — and invite guests onto named boards. On either plan a feedback form collects tickets from people with no account. Each is switched on one object at a time; there is no public view of a wiki or of a workspace as a whole.
  • The free plan is the starting point, not a locked workspace. A new workspace lands on free with no card and no deadline: one workspace, three boards, 100 MB of storage and up to three billable people. The paid plan lifts those limits and adds guests, wiki publishing, private wiki pages and public board links; it takes a card at checkout and starts straight away. See Billing.

Where to go next#