Everything it does.
Grouped by the job at hand.

FIG 1.1

Two views, one filtered set

List and board render the same filtered set, and the filter bar sits above both, so switching view never loses your filters. Neither view waits for the whole list before it shows you anything.

• Filters survive the switch
• Counts stay accurate
• Nothing to wait for

10ktasks, same speed

Lists that open at any size

A list with ten thousand tasks opens as fast as an empty one, and stays that way as the year fills it up.

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.

34MCP tools, live

Your assistant, on the same rails

Anything your assistant does goes through the same permission checks and validation as a click in the app, and leaves the same activity trail. A token can only reach the workspaces you name and do the things you tick.

• 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

When two people edit the same task at once, the second one is told and offered the newer version, instead of quietly overwriting the first.

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.