How to measure the ROI of Claude Code

To measure the ROI of Claude Code, compare the same kind of work before and after: how many hours a typical change takes, how long it takes from request to live, what each change costs once you add tool spend and review time, and how often changes need fixing afterward. Return on investment is the value of the time saved, minus everything you spent to get it, including the review time that AI-written work still needs.

There is no reliable industry figure for how much time Claude Code saves, and any article that gives you one is guessing. The numbers that matter come from your own team, measured the same way before and after you start. Anthropic says as much about cost: its cost documentation advises starting "with a small pilot group" and using its tracking tools "to establish a baseline before wider rollout."

This guide covers the four measures worth tracking, where to get the data, a hypothetical worksheet you can copy, and the claims to keep out of your report.

Why most ROI claims about AI coding tools don't hold up

ROI claims usually fail in one of three ways. The baseline was never measured, so "before" is an estimate. The "after" counts only the fast part, the draft, and leaves out review, fixes and rework. Or the figure is borrowed from someone else's company, with different work, different people and a different codebase.

Anthropic publishes customer stories with impressive numbers. Rakuten, for example, reports a 79% reduction in time to market, from 24 days to 5 days, according to Anthropic's customer story. Those figures are real for those teams and that work. They tell you what is possible, not what your marketing site's backlog will do. If you put one in a business case, label it as a customer-reported figure from another company, and don't multiply your budget by it.

The four measures that matter

Pick task types that repeat, so the before and after compare like with like. On a website, good candidates are updating a fact across many pages, writing redirect maps, fixing titles and meta descriptions, building a new landing page from an existing template, and adding structured data. Our list of practical jobs Claude Code can do on a business website is a good place to choose them.

Where the data comes from

You'll need two kinds of data: what the tool costs and does, and what your people spend. Anthropic provides the first. You have to collect the second.

• Individual plans. The /usage command shows plan usage bars, activity stats and a breakdown of what counts against your plan limits, plus a usage-credits row while usage credits are on. On Pro and Max, month-to-date usage-credit spend is under Settings > Usage.
• Team and Enterprise. Admins and Owners can open the Claude Code analytics dashboard. It shows daily active users and sessions, lines of code accepted and suggestion accept rate. With the GitHub app connected, contribution metrics, in public beta, add merged PRs written with Claude Code help, PRs per user and a CSV export. A spend report covers usage-credit spend per user and per model; usage inside the seat allowance isn't metered in dollars.
• API (Console) accounts. A separate dashboard covers usage and spend. Contribution metrics with GitHub aren't available there.
• Your own records. Time logs, ticket timestamps, deploy history and bug reports. Git history helps too: merged PRs that Anthropic's analytics attribute to Claude Code are labeled claude-code-assisted in GitHub.

Read the analytics with care. Anthropic says its contribution metrics are an underestimate, counting only lines and PRs where it has high confidence that Claude Code was involved, and code rewritten by more than 20% isn't attributed. More lines of code is not a goal on a website, either. A change that deletes a thousand lines of dead template code can be worth more than one that adds them. Anthropic's own suggestion is to use these metrics "alongside DORA metrics, sprint velocity, or other engineering KPIs," which is another way of saying they need your outcome numbers next to them.

What to count as cost

List every cost, even the ones that feel small, because they add up during a pilot:

• Subscriptions or API spend. Pro is $20 a month billed monthly. Max starts at $100 a month. Team seats and Enterprise are priced per seat, and Enterprise usage is billed at API rates. Our Claude Code pricing guide covers every plan as of October 2026; confirm current prices on Anthropic's pricing page.
• Usage beyond the plan. Usage credits are billed at standard API rates once you turn them on.
• Automation runs. If you run Claude Code in GitHub Actions, count the Actions minutes too. Anthropic's docs say runs authenticated with an API key consume API tokens, while runs authenticated with a subscription token (CLAUDE_CODE_OAUTH_TOKEN, available on Pro, Max, Team and Enterprise) use your Claude subscription instead of API billing, so they draw on the plan's usage.
• Setup time. Writing CLAUDE.md files, permission settings and review rules, and connecting tools.
• Training time. Hours people spend learning the tool instead of doing their normal work.
• Review time. Every change still needs a person to read the diff and check the result. This is the cost most ROI estimates leave out.
• Rework. Time spent fixing changes that went wrong, including after release.
• Outside help, if any. A consultant to set up the rollout, or a developer to review work. Our guide to what a Claude Code consultant costs covers how that's priced.

A hypothetical ROI worksheet

The table below is a hypothetical example with round numbers, not a benchmark or a prediction. It imagines a three-person web team on Team standard seats with monthly billing, a $50 hourly cost for the team's own staff, used only as a placeholder for your internal cost and not anyone's billing rate, and 40 changes a month of one repeating type. Replace every number with your own.

Two things in this example are worth noticing. The saving per change is modest, half an hour, because review time is included. And the rework line matters: if errors after release doubled, most of the return would disappear. That is why error rate belongs in every ROI report.

Value can also come from work that wasn't happening at all, such as a backlog of fixes nobody had time for. Count that separately and honestly, as "changes shipped that were previously deferred", rather than converting it into imaginary hours saved. For a broader comparison of in-house and outside costs, see our in-house team vs. agency cost and ROI comparison.

How to run the measurement

1. Choose two or three repeating task types and define what "done" means for each, including review.
2. Measure a baseline for two to four weeks before anyone uses Claude Code on those tasks.
3. Run a pilot with a small group. Use the same task types, the same definition of done and the same review standard.
4. Track errors for a few weeks after release, not just at merge.
5. Fill in the worksheet with measured numbers only, and write down the method next to the result.
6. Decide: expand, adjust the rules and measure again, or stop.

Our 30/60/90-day rollout plan builds this measurement into the pilot phase.

What not to claim

• No multipliers. "10x faster" or "3x productivity" can't be measured on a mixed backlog of website work. Report hours per task type instead.
• No borrowed figures as forecasts. Customer stories describe other companies' results.
• No lines-of-code value. Lines written is activity, not outcome.
• No drafts counted as shipped. Only changes that went live, and stayed live, count.
• No hiding the review. If review time isn't in the "after" figure, the number is wrong.
• No guaranteed savings in a budget request. Present a measured pilot result and a range.

We follow the same rule for our own site. Our eseospace.com rebuild case study reports what was produced, such as more than 4,400 corrections across about 750 pages, each tested on a copy first. Counts like that describe output. They become ROI only when you set them against measured time and cost.

Conclusion

Claude Code's ROI is measurable, but only with a baseline taken before the pilot, a definition of "done" that includes review, and an error rate tracked after release. Count every cost, report hours per task type rather than multipliers, and treat customer stories as context rather than forecasts. If you'd like help designing a pilot that produces numbers you can defend, our Claude Code consulting service sets up rollouts with measurement built in. More guides are in our Claude Code Guide.

Frequently asked questions