Laver
Sign in Start free

Board plus documents

Where does the writing
about the work live?

A ticket says what to do. It is a bad place for why. So the brief goes in a doc, the decision goes in a chat thread, the runbook goes in whatever the last person used — and six months later the ticket is still there and the reasoning is gone.

Create your workspace How the wiki works

Free for one workspace, 3 boards and 100 MB · £2.99 incl. VAT per seat per month beyond that · viewers are free

THE DRIFT

Two tools, two lists
of who can read.

The cost is not the second subscription. It is that the two halves are governed separately, and they only have to disagree once.

  • Access decided twice

    Someone joins and is added to the board. Nobody adds them to the docs. They spend a fortnight asking questions that are already written down, or worse, guessing.

  • Offboarding that half-happens

    Someone leaves and loses the board. Whether they lost the documents depends on whether the person doing the offboarding remembered there were two systems.

  • The thread that was the decision

    The reasoning is in a chat message from a Tuesday, findable only by someone who already knows it exists. That is not a knowledge base, it is an oral tradition.

WHAT LAVER DOES

One workspace,
one membership list.

The wiki belongs to the workspace, not to a board. Access is decided once, and both halves stay in step because there is only one list.

  • A tree of pages, written together

    Nested pages with history and attachments, and full-text search across all of them. The brief, the runbook and the reason you chose the thing you chose sit beside the tickets that came out of them.

    Two people can be in the same page at once. You see the other person's cursor with their name on it, and who else has the page open before you start rewriting a paragraph — and ticket descriptions work the same way, because it is the same editor.

    Wiki pages

  • Add someone once

    A workspace member can read the wiki. There is no second permission model to keep in step, and no way to be on the board but locked out of the writing about it — unless a page has deliberately been made private, which is the one exception and is set on the page itself.

    Roles and permissions

  • Remove someone once

    Deactivating a member removes both halves at the same moment — and it disables any API keys they issued, so an agent they set up stops with them.

    Offboarding

HONEST FIT

One list cuts both ways.

The thing that makes this simple is also its limit, and it rules some teams out.

A good fit when

  • Everyone with a login is a colleague, and most of what you write is meant for all of them.
  • The writing you care about is briefs, runbooks and decisions — not a public help centre.
  • You have been meaning to consolidate two subscriptions into one.

Not what this is

  • Page permissions are per person. A page is visible to the whole workspace, or it is private and shared with named members one at a time. There are no groups to grant it to.
  • Publishing is one page at a time, and read-only. On the paid plan a single page can be given a public link that anyone can read without a login; it is not indexed and it carries no editing. A board can be published the same way, as a read-only roadmap — but there is no public view of the wiki as a whole, or of a workspace. Everything else needs an account.
  • No comments on wiki pages.
  • Not a document editor and not a spreadsheet.

READY WHEN YOU ARE

Put the why beside the what.

Every workspace comes with a wiki already in it. There is nothing to connect and nothing to keep in step.

Create your workspace

Keep reading