Per-contributor pricing, explained
Updated
Per-active-contributor pricing bills for people who actually committed code in a window, rather than everyone with a login. It aligns cost with usage better than per-seat, and raises one new question: exactly what the meter counts, because no definition of active contributor is self-evident.
This guide covers what the meter has to decide, the questions worth asking any vendor that uses one, and the failure modes on both sides — including the ones that make a per-contributor bill spike for reasons that have nothing to do with hiring.
What per-seat gets wrong, and what per-contributor changes
Per-seat pricing bills for accounts. In a tool that a whole engineering organization can read but only a subset actively feeds, that means paying for a long tail of dormant logins — which produces a predictable behaviour: teams stop granting access, and the tool stops being the shared source of truth it was bought to be.
Per-active-contributor pricing bills for observed activity in a trailing window instead. Someone who read a dashboard costs nothing; someone who shipped code counts. That removes the incentive to ration access, and moves the cost question to the meter's definition — which is now the thing worth scrutinising.
- Per-seat penalises sharing; per-contributor does not.
- The billing question moves from 'who has a login' to 'what counts as activity'.
- A meter definition you cannot inspect is a price you cannot check.
What the meter has to decide
Any per-contributor meter makes at least four decisions, and a vendor that has not published them has still made them. The trailing window sets how quickly the bill responds to a team shrinking. Identity resolution decides whether one person committing from a work laptop and a personal machine is one contributor or two. Bot handling decides whether an automated dependency-update account is billable. And a minimum, if one exists, sets the floor below which the price stops falling.
Identity resolution is the one that surprises people. A single engineer can appear under several git identities across forges, and a meter that does not deduplicate them bills for the same person more than once. A meter that deduplicates too aggressively — merging on a shared display name, say — undercounts and will eventually merge two different people.
| Decision | Why it matters | Question for the vendor |
|---|---|---|
| Trailing window | Sets how fast the bill reacts when a team shrinks — and how long a contractor keeps costing. | How many days, and is it a rolling window or a calendar period? |
| Identity resolution | Whether one person with several git identities is billed once or several times. | What links two identities? Verified email, linked account, or a display-name match? |
| Bot and automation accounts | Dependency bots and CI accounts commit constantly and are not people. | Are bot accounts excluded, and how are they identified? |
| Minimum billable contributors | A floor makes the price predictable for the vendor and can make a small team overpay. | Is there a minimum, and does it apply on every tier? |
Failure modes on both sides
For the buyer, the classic surprise is a bill that moves for reasons unrelated to headcount: a large one-off migration executed under a service account, an open-source contributor whose commit landed in an internal mirror, or a monorepo consolidation that pulls previously separate histories into the counted window. None of these represent more people using the tool, and all of them can move a contributor count.
For the vendor, the mirror-image risk is revenue that swings with a customer's release calendar rather than their commitment, which pushes vendors toward minimums and annual terms. A floor is not inherently unfair — it is how a vendor makes revenue predictable enough to support a small customer at all — but it should be stated in the price, not discovered on the invoice.
- Ask to see the counted identities for a period, not just the total. A number you cannot decompose is a number you cannot dispute.
- Check how a one-off migration or a bulk import is treated before it happens.
- Confirm whether the floor applies per tier; a floor on an entry tier excludes exactly the small teams it appears to serve.
What good looks like
A per-contributor meter is defensible when its definition is published, its output is decomposable to the identities it counted, and a disagreement has a route to resolution that is not an email to sales. Those three properties do more for trust than the price point does, because they turn the bill into something a buyer can check rather than accept.
If a vendor cannot show you which contributors it counted for a period, the meter is not auditable — and an unauditable usage meter is a recurring act of faith, whatever the number on it.
Frequently asked questions
What counts as an 'active contributor'?
It varies by vendor, which is why the definition matters more than the price. Typically it means a distinct human identity that authored at least one commit within a trailing window, with bots excluded and identities deduplicated across forges. Ask for that definition in writing — the window length, the deduplication rule, and the bot-exclusion rule — before comparing two vendors' rates.
Does per-contributor pricing punish us for using AI coding agents?
It depends entirely on whether the agent commits under its own identity and whether the vendor treats that identity as a bot. Ask directly. A meter that bills for an agent account is charging you for automation, which is the opposite of what a per-person price is supposed to represent.
Is a contributor minimum reasonable?
It can be. A floor makes revenue predictable enough for a vendor to serve small customers, and a stated floor is very different from a surprise one. The question worth asking is whether the floor applies on the entry tier — a minimum there excludes precisely the individual developers and small teams that tier appears to be for.
How do we forecast the bill?
Count distinct commit authors in your own version control over the vendor's stated window, applying their deduplication and bot rules as best you can, and compare that to the number they report. If the two disagree materially, the difference is a question worth resolving before signing rather than after.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.