Everything is a board.
Anything can become a workflow.
Typed columns, groups and views — then layer on the rules that make it a real process: who sees, who edits, who approves.
Columns with real types
Status, person, date, number, dropdown, files — validated end to end, so a cell the interface would refuse to draw is a cell the API refuses to store.
Approvals without a module
Any status can require a manager. Decisions notify the right people and freeze the row until someone entitled reopens it.
Self-service for everyone
Employees request leave, check balances and track decisions from one simple page — no training required.
Availability, not surveillance
Colleagues’ absences appear as unnamed lanes — enough to plan a request around, nothing that says who is away.
Reminders with an audience
Per-column schedules — 60, 30, 7 days out — sent to exactly the people each column names.
Permissions that hold
Hiding a button is not a control. Every rule is enforced as row-level security in Postgres, so it binds the interface, the API — and anyone who tries to go around them with a raw request.
One request, end to end.
No automations to wire, no integrations to buy — the lifecycle is what the board’s rules already mean.
The rules
are settings.
Private statuses, locked statuses, who may edit whose rows, who approves — a board’s whole behaviour is the panel beside it, and every change lands the moment you save it.
- Name your rows. A board of employees says "employee"; a purchasing board says "purchase order" — everywhere, automatically.
- Gate anything. Who sees a column, who edits a row, which statuses only managers may set — all settings, all instant.
- Change your mind safely. Every rule takes effect immediately, with no migrations and no rebuild.