For software teams
Most project tools are built for people who plan work, not for the people and scripts that also need to read and write it. IterDone tracks a sprint the way an engineering team already thinks about one — statuses, dependencies, a burndown of what's actually done — and then opens the same data to a REST API, outbound webhooks and a built-in MCP server, so the tracker isn't the one system your CI pipeline and your AI assistant can't touch.
How it actually plays out
Six workflows an engineering team runs every sprint, mapped onto what the product does today.
Run a list per sprint, or a folder per epic that spans several. Attach a goal with a numeric target — story points closed, bugs resolved — and watch it roll up automatically as tasks move to done, so "how's the sprint going" has a number behind it instead of a gut feeling in standup.
Draw a dependency between two tasks and the timeline tells you what slips when something slips — before it's a surprise in the retro. Mark the release date as a milestone and the whole team can see, at a glance, whether the chain of work behind it still lands on time.
Cap "In Review" at the number of pull requests one reviewer can realistically get through, and the board makes the bottleneck visible before it's a pile of stale branches. Custom statuses mean the board matches your actual pipeline — Backlog, In Progress, In Review, QA, Done — not a generic three-column default.
A public form takes bug reports from anyone — a support rep, a beta user, a stakeholder — without them needing an account, and the submission lands directly in the bug list. Custom fields for environment, severity and repro steps mean the details you'd normally chase down in a comment thread arrive as structured data from the first message.
Add exactly the fields an engineering list needs — environment, severity, affected version, a link to the failing build — without those fields showing up on a list that doesn't need them. Filter and save a view for "Severity: Critical, Status: Open" once, and stop rebuilding it every stand-up.
119+ documented REST endpoints behind scoped API keys mean CI can open a task when a build fails and close it when the fix merges. Webhooks push status changes into Slack. And the built-in MCP server hands an AI assistant 87 tools — create a task, read a sprint, log time — so the tracker can be driven from a conversation, not just a UI.
Getting a team live
No migration project and no separate admin console to configure before the first ticket gets tracked.
Upload a CSV from whatever you're on now — names, statuses, priorities, assignees and due dates come with it. About two minutes.
They log in and see their work. There's nothing to teach them, because there's nothing hidden.
Adjust statuses, add the two custom fields you actually need, and get on with the work.
Common questions
Yes. The REST API exposes the same actions the UI does — create a task, move a status, set a custom field — behind a scoped API key, and outbound webhooks can notify your pipeline the other direction when something changes.
It exposes 87 tools directly to an MCP-compatible AI assistant — creating and updating tasks, reading lists and sprints, logging time, adding comments — so the assistant can act on the tracker instead of just describing what's in it.
Dependencies record what has to happen first and surface it clearly on the timeline and the task itself, so the team sees a blocker before it becomes a missed date — the same information a stricter enforcement model would give you, without the friction of a hard lock.
Keep exploring
Sign up, generate a scoped key, and start the sprint. The MCP server is already on.