Everything it does.
Grouped by the job at hand.

FIG 1.1

Two views, one filtered set

List and board render the same scoped query, and the filter bar sits above both — switching view never drops your scoping. Neither view fetches everything: rows arrive behind a cursor while the counts come from the server.

• 20 rows per page
• server-side counts
• cursor, not offset

10ktasks, same speed

Lists that open at any size

Keyset pagination everywhere, so a list of ten thousand tasks opens as fast as an empty one.

Subtasks, five levels deep

Deep enough for real decomposition, capped so nobody builds a tree the team cannot read.

FIG 1.2

Dates you can drag

Month, week and day views, drag-to-reschedule, and week swimlanes for a whole team at once. Roadmap milestones sit on the same grid.

Workspace → space → folder → list

A hierarchy that matches how teams already divide work, instead of one flat bucket of tasks.

Custom fields where they belong

Defined on a space or a single list, with editors for text, number, date, select, multi-select and checkbox.

A roadmap above the spaces

Initiatives across quarters with milestones, health, and progress rolled up from the spaces beneath.

32MCP tools, live

Your assistant, on the same rails

Every Model Context Protocol call runs through the handlers, permission checks and validation a click goes through, and writes the same activity record. A token’s authority is its scopes intersected with its workspaces.

• 22 scopes
• 120 requests/minute
• revocable, expiring

FIG 2.1

GitHub work, attached to the task

Issue, branch and pull request links with commit and PR tracking, and a diff you can read without leaving the task.

One pipeline, three doors

A click, a tool call and an API request take the same path. There is no faster, looser way in.

A REST API with the same model

Scoped tokens, the authorization pipeline MCP uses, and a monthly request quota per tenant.

Actions attributed to a person

Reads use one business token; writes use each member’s own, so GitHub shows who actually did it.

Realtime, not refresh

Boards, lists, task drawers and the inbox update as your team works.

Two people, one task, nothing lost

Optimistic concurrency gives simultaneous edits a merge path rather than a silent last-write-wins.

FIG 3.1

A queue, not another inbox

Submissions land in one triage view. Approve to create a task, merge into the task that already exists, or reject with a reason and an image — the reporter stays linked either way.

• approve
• merge
• reject with a reason

One script tag, no account

The widget embeds in your own product and takes bugs and feature requests from people who never sign in. It carries your colours, and runs anonymous or identified.

Publish the ones you will do

Feature requests become a voteable public board, in the widget and on a standalone page.

The reporter hears back twice

Acknowledged on submit, emailed again when it ships — including merged duplicates.

A reference they can quote

Every submission gets a short code that appears in the subject line of every email about it, so the thread stays findable in the reporter’s own inbox.

Dashboards that click through

Throughput, cycle time and workload widgets, each one opening the tasks it counted rather than leaving you to reconstruct them.

FIG 4.1

Every status change, timestamped

The transition is written the moment it happens, so time-in-status is read back rather than remembered. Cycle time ends up a measurement instead of a number estimated at the end of the sprint.

Person analytics, section by section

Per-person views split into sections, with drilldowns that page as you scroll.

Workspace stats at a glance

Totals, completed and overdue, plus the split by status and priority — counted server-side.

Who actually has capacity

Team availability read from the work already assigned, rather than from a spreadsheet of guesses.