To compare quotes priced on different metrics, convert each one to a total cost over three years using your own current counts and your realistic growth. Include add ons, support tiers and overage rules. The cheapest line on page one is often not the cheapest tool by year three.
Write down your usage baseline
Collect these numbers before asking for prices:
- Active developers who commit in a typical quarter
- Repositories you want covered, split into active and archived
- Pipeline runs or scans per month
- Lines of code in scope, if a vendor prices that way
- Applications or services, if that is the unit
Use what you have, not what you hope to have. Then add a growth assumption, such as the number of new repositories you expect next year, and use the same assumption for every vendor.
Common pricing units and what they punish
- Per developer. Punishes large teams and read only stakeholders if they need seats. Rewards teams with few developers and many repos.
- Per repository or application. Punishes microservice sprawl and monorepo splits. Rewards teams with few large repos.
- Per scan or pipeline run. Punishes frequent builds and teams that scan on every commit. Rewards low CI volume.
- Per line of code. Punishes large legacy code. Can be hard to forecast.
- Platform fee plus usage. Predictable base, but check where the usage tiers start.
None of these is wrong. The question is which one your own growth stresses.
Normalize with one worked method
Build a simple sheet with one row per vendor and one column per year. For each cell include:
- Base license
- Add ons you actually need, such as extra scan types or single sign on
- Support tier you would really buy
- Expected overage at your growth assumption
- One time costs, such as onboarding or training
Then run three scenarios: current usage, plus 50 percent, and plus 100 percent. A vendor that looks cheap at current usage but doubles at plus 100 percent tells you something about renewal risk.
Illustrative only: if a per developer quote is flat while your repo count doubles, and a per repository quote doubles with it, the per developer option gets relatively cheaper. If your headcount doubles and repos stay flat, the reverse happens. Use your own numbers.
Ask about the hidden items
- Are read only users free?
- Is single sign on included or an add on?
- What happens at the usage limit: block, overage charge or forced upgrade?
- Is there a cap on annual price increases at renewal?
- Are API calls, retention and exports limited?
- Is there a charge to leave, such as an export fee?
Get these answers in writing. Add them to the reference call list as well.
Keep price out of early scoring
Score quality first, then bring in cost. If price is visible during technical scoring, evaluators quietly adjust. Use cost to separate vendors who scored within a few points of each other.
Quick check
Should I accept a multi year discount?
Only with an exit clause tied to missed service levels or failed data terms. A discount is worth less than being locked into a tool that does not fit.
What about free tiers?
Use them for a pilot, but check the limits and the paid step up before building a workflow on them.
Last reviewed: 19 October 2026.
