Business Case

Sooner or later an engineer has to convince someone who will never read the diff that a change is worth shipping. That conversation usually goes badly, for a predictable reason: the engineer argues by hand ("it's cleaner", "customers want it", "it's better") and the person deciding hears no number, no moment a customer notices, and no idea of what it costs if it goes wrong. A Business Case is Firetrail's answer: one page written for that person, in their language, built from the change itself and from what Firetrail already knows about it.

The page has two halves, and it keeps them apart on purpose.

The facts are the effects you can measure. Six lenses: revenue, cost, retention, acquisition, risk and speed. Every fact names the metric that moves, the direction, and — the part that earns a finance reader's trust — how sure it is and where the number comes from: measured (a number that exists, in Firetrail's analysis, in the repository's own data, or in figures the team provided), estimated (derived from data, with the formula shown) or assumed (a belief, said out loud). Nobody invents a revenue figure. If a change has no measurable revenue effect, the case says it is a retention or a cost case instead.

What the customer will feel is the other half, the one engineers usually leave out because it can't be put on a dashboard the week after release — and the one that decides whether someone buys again. Six lenses here too: trust, ease, delight, control, reputation, and team confidence (the internal one: engineers less afraid of an area). Each entry names the exact moment the customer notices it, what in the change creates it, and how it turns into a number later — staying, paying, recommending.

Around those two halves the page carries what a decision maker asks for:

The recommendation first — ship, ship with conditions, hold, or needs information — with the main reason and what must be true before shipping.
What the change is, in plain words, and where it lands on the customer's path (discover, try, adopt, pay, stay, recommend).
What it costs — what is already spent and what remains, what keeping the code will cost (Firetrail's Future Debug Cost forecast, in words), operations, and how hard the change is to undo.
Risks — the engineering risks Firetrail found in the change (the classifiers that fired, the review team's objections, what was promised but not delivered or shipped without being mentioned, files with a history of causing bugfixes, thin test coverage) beside the business risks the case adds.
If we don't ship — the cost of doing nothing, which decision makers compare every change against and engineers rarely state.
What would change this recommendation — the beliefs the case rests on, what happens if each is wrong, and how to check.
The case, in each reader's language — two or three sentences for the founder, for finance, for product, for customer success, for the engineering lead.
How we'll know it worked — the metrics to watch after shipping, as a checklist.
Numbers from Firetrail — the measured half: the size of the change against this repository's typical PR, the Future Debug Cost and where it sits among the repository's other analyzed PRs, test coverage, the review team's verdicts, promised vs shipped, the bugfix history of the touched files, and the repository baseline (how often merged PRs here turn out to be bugfixes).
How to read this page — what every lens means, in the same words on every case, so an engineer who has never written one learns the vocabulary the people deciding already use.

The page prints cleanly to PDF from the browser when someone wants a file to attach to the decision.

How it's built

Your own coding agent (Claude Code, Cursor, Codex, VS Code or any MCP client) does the reading, in your checkout, on your own account. It reads the PR, the diff and the repository for business context — README and docs, pricing or plan definitions, analytics events, feature flags, onboarding and billing flows, runbooks — and writes the case as data. Firetrail contributes the numbers it already has from analyzing the PR and from the repository's history, keeps the two halves apart, checks that every fact carries a confidence and a source, renders the page and hosts it at its own link. The teaching copy beside every lens is Firetrail's, identical on every case. Firetrail never reads your working tree and runs no AI of its own for a case.

Writing one

Connecting your agent to Firetrail takes two steps, once per person (see Firetrail MCP, or the Firetrail MCP page in your account menu): create a personal token, then add the Firetrail server to your agent with the snippet the page shows for it.

Then, in a checkout of the repository, ask the agent:

Business case for PR 123 with Firetrail

(In Claude Code the slash command /mcp__firetrail__business_case 123 is the exact equivalent — that is Claude Code's naming for anything an MCP server provides; both do the same thing.)

If Firetrail hasn't analyzed the PR yet, or the PR has new commits since the last analysis, Firetrail analyzes it first and the agent waits — the analysis is the measured half of the case. The agent then hands the case to Firetrail, which renders and hosts the page and returns the link. Republishing a case later keeps the same link, so the page a stakeholder bookmarked stays current.

Availability

Business Case is on every plan. The reading and the writing run in each developer's own coding agent, on their own account, so Firetrail doesn't meter that part; the page is rendered from what the agent reports and from analysis Firetrail already ran, at no extra cost. The measured half is as rich as your plan's analysis: a Free organization's case carries the Future Debug Cost, the classifiers and one reviewer; Starter has three reviewers; Pro adds intent drift and six reviewers; Business has all ten reviewers and adds the bugfix history from origin tracing. Like every Firetrail artifact, the page is private to your organization by default and can be flipped to a public link when you want to share it beyond your team.