Skip to content
Toado Docs

Companies & projects

Toado’s data model is intentionally small. Five concepts cover everything: user, company, project, column, ticket.

The model

user (you)
  ├── member of company A
  │     ├── project A1
  │     │     ├── column "To Do"
  │     │     │     ├── ticket
  │     │     │     ├── ticket
  │     │     ├── column "In Progress"
  │     │     ├── column "Done"
  │     ├── project A2
  ├── member of company B
        ├── project B1

A user can belong to many companies. A company contains many projects. A project has its own kanban board with columns. Tickets live in columns and are scoped to a project.

User

The account you sign in with. One email, one user. A user can:

  • Be a member of multiple companies.
  • Have different roles in each company.
  • Create personal API tokens that are scoped to specific companies or projects.

Company

The top-level container for almost everything: members, projects, billing, settings, role assignments.

Common patterns:

  • Solo dev: one company called your name or your business.
  • Agency: one company per client, plus an internal company for your own projects.
  • Startup: one company for the whole org, multiple projects (web app, marketing site, mobile, etc.).
  • Multi-product: one company per product line.

You can be in as many companies as you want. Switching companies in the UI is one click in the top nav.

Project

A kanban board, scoped to a company. A project has:

  • A name.
  • Optional URL patterns (used by the extension to auto-pick a project at capture time).
  • A column set (default 3, configurable).
  • Tickets.
  • Per-project settings.

Tickets cannot move across companies, but they can move across projects within the same company. See Archive & restore › Cross-project moves.

URL patterns are how the extension knows which project a capture belongs to. See Capturing › Project assignment.

Column

A vertical lane on the kanban board. Default columns: To Do, In Progress, Done. Configurable per-project (rename, add, remove, reorder).

Common additions:

  • In Review between In Progress and Done.
  • Blocked for tickets waiting on something external.
  • Won’t Fix as a triaged-out lane.

There is no enforced workflow. Any column can move to any other column.

Ticket

A captured bug, feature request, or piece of work. A ticket has:

  • A title (often AI-generated from the capture; editable).
  • A description (markdown).
  • A capture payload (screenshot, console, network, errors, performance).
  • Annotations (overlay shapes drawn on the screenshot).
  • Comments.
  • Attachments (extra images uploaded by the user).
  • Assignees.
  • A column.
  • A resolved flag (separate from column).
  • An optional branch name.
  • Standard timestamps (created, updated, archived).

Tickets are immutable in identity (the id is permanent) but every field above is editable.

What is not in the model (yet)

These are out of scope for v1 and may show up later:

  • Tags / labels on tickets.
  • Sub-tickets or task hierarchies.
  • Sprints / milestones / iterations.
  • Time tracking.
  • Custom fields per project.
  • Workflow rules (e.g. “moving to Done requires approval”).

If any of these matter to you, the feature request page is the place to vote.

Multi-tenancy

A user only sees companies they are a member of. Tokens can be restricted further (to specific companies or projects). The data model enforces multi-tenancy from day one; there is no “all-companies” view that would leak data across tenants.

Where to next