From a request to a forecast, in four moves
The same loop for a client follow-up and a production bug, and the same loop whether a person or an agent does the step. Nothing here is a hand-off between tools: each move leaves the work in the state the next one expects.
Capture, and let triage route it
Work arrives from four places and lands in one queue. Press C in the app, type /falrow create in Slack, convert a reviewed client meeting, or let your agent open the ticket itself.
- Bug, change, feature or task, each type with its own default owner and starting stage
- Up to 20 ordered triage rules match the title or the source and set owner and labels
- Snooze for an hour, a day or a week, or resolve it as a duplicate
- Templates for the tickets you open over and over
Plan the cycle
Pull the routed work into a scheduled cycle, check capacity per person while you are doing it, and attach the milestones the roadmap is counted from.
- Recurring schedules for the whole workspace or per project, 1 to 56 days with a cooldown
- Up to 12 cycles planned ahead
- Milestones with a status, an owner and target dates
- Unfinished work rolls over after you review it, or automatically
Build with your agent
Open the repository. The agent sends the git remote, the workspace answers with that application's plan, and the agent updates tickets as it goes.
- plan_context matches the remote to an application and returns its stack, owners and open tickets
- Every write carries the version it read, so a stale write is rejected rather than applied
- Bulk edits of up to 100 tickets are all-or-nothing
- Links, Markdown and text documents ride along on the ticket
Measure, then forecast
The report is rebuilt from each ticket's recorded history rather than from its current state, so work that moved project, reopened or was deleted still counts where and when it really was.
- 12 sections: cumulative flow, time in stage, lead and cycle time percentiles, aging and blocked work
- A Monte Carlo forecast over 2,000 runs for P50, P85 and P95 dates
- Below 4 complete weeks and 10 completions it says so instead of guessing
- Saved reports you can share
From the client call to the cycle, without retyping
If you build for clients, the reason behind a ticket is usually a conversation. Falrow keeps the customer, the meeting and the resulting tickets linked, so the developer and the agent can both see why the work exists and who it is for.
## Next steps
- Add Arabic to the booking flow
- Send staging link for sign-off by Friday
- Quote phase two: staff scheduling
- Ask about their hosting contract
Your coding agent works from the real plan
Falrow runs its own MCP server on the same database as the app. Claude Code, Codex or any MCP client signs in once, then reads the plan for the repository it is standing in, picks up tickets and records progress, with the permissions of the person who connected it.
An illustration with demo data. Tool names and behaviour are the server's own.
# your workspace's MCP endpoint
claude mcp add --transport http \
falrow https://<your-workspace>/api/mcpBrowser sign-in with OAuth and a consent screen, or a workspace token that expires after 90 days. Plus an agent package with a development workflow skill for Claude Code and Codex.
The rules are on the records, not on the person following them
A process that depends on everyone remembering it stops working the week someone is on holiday. These are checked by the service layer, so the app, Slack, the API and every agent get the same answer.
Run one real cycle on it
Bring a project that already exists, not a sandbox. We set the workspace up with you and watch the first cycle through.