Tools to measure developer productivity, compared

Every tool sold as a way to measure developer productivity reads one of two things: your git history, or your developers. The first kind counts pull requests, cycle time and deploys. The second kind runs surveys and turns the answers into a score. The serious platforms now do both, because the research behind all of them says neither works alone.

Below are the ones worth evaluating in 2026, what each actually reads, and what it costs where the vendor publishes a price. Then the part other listicles skip: four well-known names in this category are no longer the products those listicles describe.

The tools, side by side

Tool	What it reads	Published price	Free tier
DX	Surveys and git telemetry	Not published	No
LinearB	Commits, PRs, deploys, plus surveys	$29/user/mo annual, 50 developer minimum	No, 45-day trial
Jellyfish	Git and PRs, plus calendar, finance and HR data	Not published	No
Swarmia	PR cycle time, batch size, DORA, plus surveys	$45/developer/mo annual	Yes, up to 9 developers
Waydev	Git, PRs, DORA, AI adoption and token cost	$29/contributor/mo	Yes, 10 repos, 3 months of history
Faros AI	60+ sources, attributes AI token spend to outcomes	Consumption based, not published	No
Oobeya	Git, CI/CD, tests, code quality	Not published	Demo only
Keypup	Git and Jira, queried in natural language	Not published	Trial
Haystack	PR flow, capacity, epic progress	Not published	14-day trial
Apache DevLake	Git, trackers, CI, with DORA dashboards	Free, self-hosted	Open source
DevSummary (ours)	Commits and diffs, written up as a report	$9/mo	Yes, 1 repository

Prices were read off each vendor’s own pricing page on 15 September 2026. Where a vendor does not publish a price, the cell says so rather than guessing. The last row is ours, and the section at the end explains why it sits on a different shelf from the nine above it.

Two things stand out from that table. Most of this category will not tell you what it costs until you take a sales call, and the two that will (Swarmia and Waydev) are also the two with a usable free tier. If you have fewer than ten engineers, start there.

The two kinds of tool, and why the good ones do both

Git telemetry is cheap to collect and easy to misread. It shows cycle time, review latency, deploy frequency and where work sits waiting. What it cannot see is why. A pull request open for nine days looks identical whether the reviewer was on holiday or the change was badly scoped.

Surveys cover that blind spot. The DevEx framework, published in ACM Queue in 2023 by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, boils developer productivity down to three things you mostly cannot instrument: how fast feedback arrives, how much mental load the work carries, and whether anyone gets uninterrupted time to think. You find those out by asking.

DX, the vendor behind that research, published a combined model called DX Core 4 in January 2025 that folds DORA, SPACE and DevEx into four dimensions: speed, effectiveness, quality and business impact. Every platform in the table above now claims some version of that combination. It is the current consensus, and it is why a tool that only counts commits is a generation behind.

Four tools other lists still recommend

This category consolidates fast, and the listicles do not keep up. As of September 2026:

Pluralsight Flow. Pluralsight bought GitPrime for $170 million in 2019 and rebranded it Flow. Appfire acquired Flow from Pluralsight in February 2025, and competitors have been circulating an end-of-life date ever since. Ask Appfire directly what the roadmap is before you sign anything.

Code Climate Velocity. Visit codeclimate.com today and you get a consulting business selling AI transformation engagements. Velocity is not mentioned anywhere on the page.

Athenian. athenian.com now redirects to the company’s GitHub organisation. The code is still there and still getting commits. The commercial product does not appear to be.

Sleuth. Still trading, but it sells something else now. The site sells governance for AI agents: token usage, cost per skill, declared versus actual deployment state. If you are looking for the DORA tracker it used to be, that product is gone.

Google’s own reference implementation, Four Keys, is also finished. The repository has carried this notice since January 2024: “This repository is not currently maintained. We encourage you to explore it, fork it, or otherwise use it as inspiration for your own metrics instrumentation.” If you want DORA metrics for free and self-hosted, Apache DevLake is the maintained option.

The people who built these metrics tell you not to use them this way

Before you buy anything, read what the frameworks say about themselves.

DORA now defines five metrics rather than four, having added deployment rework rate in 2025. The same page carries two warnings. One is about targets: “Ignoring Goodhart’s law and making broad statements like, ‘Every application must deploy multiple times per day by year’s end,’ increases the likelihood that teams will try to game the metrics.” The other is about comparison: the metrics “are meant to be applied at the application or service level,” and comparing them between very different applications “can be misleading.”

The SPACE framework opens by saying productivity “cannot be measured by a single metric or dimension,” which rules out the dashboard number most buyers are shopping for.

And when Kent Beck and Gergely Orosz responded to McKinsey’s developer productivity framework in 2023, Beck described what happened when scores like these reached compensation at Facebook: “Directors put pressure on managers for better scores. Managers started negotiating with individual contributors for better survey scores.” Their objection to the framework itself was that nearly every metric in it measured effort or output rather than outcome.

None of that makes the tools useless. It makes them team-level diagnostics rather than a scoreboard, which is also what DORA metrics can and cannot tell you on their own, and why counting lines of code fails for the same reason one level down.

Your throughput line means something different now

If you install one of these in 2026 and the throughput chart goes up, be careful what you conclude.

Google’s 2025 DORA report, based on a survey of around 5,000 technology professionals, found 90% of respondents using AI at work and more than 80% believing it made them more productive. It also found a catch: “AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.”

More changes, moving faster, breaking more often. A tool that reports volume will show you the first half of that and not the second, unless you are also watching change fail rate and recovery time.

What none of them tell you

Every tool above answers one question in a different way: how is the team working? Cycle time, review load, deploy cadence, how people feel about their tooling. That is genuinely useful if you run engineering and can act on it.

It is not the question a founder or a board member is asking. They want to know what got built, and that answer is not a number. It is a sentence: customers can now pay by invoice, signups stopped failing silently, the migration is done.

That sentence exists already, written in commit messages and diffs nobody outside the team can read. Usually someone senior translates it by hand on a Friday until they quietly stop. DevSummary is ours, so weigh the rest of this paragraph accordingly. It reads your GitHub activity and writes that translation on a schedule, scoped to a project, a team, a person or a repository, delivered to Slack or email.

It does carry numbers next to the writing: commits per day, lines added and removed, which repositories moved, who committed, the busiest day, each compared against the previous period. What it does not have is what the other nine are built on. No DORA metrics, no developer experience surveys, no cycle time or review latency. The report is the product and the charts are context under it, which is the opposite of how a measurement platform is put together.

So pick on the question you actually have. A measurement platform for the engineers who can act on the numbers, a written report for everyone else. Plenty of teams need both, and neither one substitutes for the other.

Common questions

What is the best tool to measure developer productivity?

For teams under ten developers, Swarmia’s free tier or Waydev’s free plan will tell you most of what you want at no cost. Above that, LinearB and Swarmia publish their pricing so you can budget without a sales call, and DX and Jellyfish are the ones large organisations tend to end up on. If what you actually want is DORA metrics and nothing else, self-host Apache DevLake.

Can these tools measure individual developers?

Most can produce per-person views, and most vendors will tell you not to use them that way. DORA’s own guidance warns that metrics become targets and targets get gamed, and Kent Beck’s account of scores reaching compensation at Facebook is what that looks like in practice. Use them to find where work gets stuck, not to rank people. The team-level practices worth adopting instead do not need a dashboard.

Do I need a productivity tool at all?

If you cannot say what your engineering team shipped last month, a metrics platform will not fix that, because it does not measure it. Start with the four checks in how to know if your dev team is working well and a written engineering update. Buy a measurement tool when your engineering lead has a specific question about flow that they cannot answer from the repository by hand.