%20(1).png)
For most of AppSec's history, developer headcount was the only reliable number available, so it became the number the market priced against. More developers meant more code. More code meant more risk. Seat-based pricing and seat-based TAM models followed, and both held up for over a decade.
They don't anymore. And the TAM is considerably larger than the seat-based spreadsheets suggest.
The market was built on a correlation, not a cause
The old math was clean. As of 2021 there were roughly 28 million developers worldwide, about 60% of them at companies with more than 50 employees. Blend a per-seat price across the usual module set, SAST, SCA, secrets scanning, IaC, ASPM, and you land somewhere around $500 per developer per year. Multiply it out and the AppSec TAM comes to roughly $8.4 billion, projected to climb to around $14 billion by 2030 on the back of 3 to 5% annual headcount growth.
Not bad.
The model made sense because the correlation held. One developer produced roughly one developer's worth of code, so headcount was a fair stand-in for output. The seat was a unit that meant something. Every AppSec pricing page, and most of the TAM decks behind them, still run on that assumption, projecting the market forward by projecting hiring forward.
Five years later, professional developer headcount still grows in the low single digits. Code output left that curve. GitHub processed 986 million commits in 2025, a 25% jump in a single year after a decade of low-teens growth. Platform totals blend many things together, including a record year of new signups, so treat that number as directional.
The per-developer data is where the break shows up. Cursor's usage data shows mean lines added per developer per week climbing from 3.6K to 8.6K in about seventeen months. Lines added per pull request at the 75th percentile are up roughly 2.5x year over year. The growth rate is still accelerating.
Per seat pricing models stopped meaning anything.
Beyond volume, the seat itself stopped functioning as a stable unit. A marketing manager with the right tooling can ship more code in an afternoon than some backend engineers ship in a week. A team of ten, properly equipped, outproduces a team of hundreds running outdated practices. None of it shows up in a headcount projection, because headcount was never measuring output. It was measuring who had a badge and a laptop.
When a badge reliably produced a predictable amount of code, per-seat licensing made sense. Now a single seat can produce zero lines in a week or a thousand in an hour, generated by a swarm of agents running continuously against a codebase. A unit that can represent either reality at any given moment isn't a unit worth pricing against.
Once headcount stops tracking output, pricing products or sizing the market on it stops making sense. Code defines the attack surface, not the developer who happened to be logged in when it was written. Pricing and sizing product security against code produced is a straightforward correction.
The formula changed in five years:
2021: [seats] x [security modules]
2026: [code volume] x [risk]
Run the napkin math and the $14 billion 2030 projection looks conservative. A market growing in the low single digits and a market compounding past 25% a year part company fast. Within a few years they are no longer versions of the same forecast. They are different markets.
Not all code deserves the same scrutiny
The argument comes with an obvious caveat. Raw line counts aren't the whole answer, because all lines aren't created equal. A payment service and an internal dashboard do not deserve the same scan frequency, the same review depth, or the same scrutiny, even if they produce a comparable number of commits in a given week.
The real unit is risk-weighted code: what a change touches, who and what can reach it, how exploitable it is once it ships. Weight the volume by risk and the growth story holds. Risk-weighted volume grows slower than raw lines, since agents generate plenty of scaffolding and tests, but it still compounds an order of magnitude faster than headcount. The caveat narrows the number. It doesn't rescue the seat.
Risk weighting is also why validation matters more than finding count. A scanner that produces more alerts as code volume grows is describing the problem faster, at higher cost. Sizing and pricing against code volume holds up only if the code being counted is weighted by what it can do to the business.
Are we moving to consumption based AppSec?
I can't speak for the market. I can speak for Prime: we priced the product on consumption, because seats no longer count anything. Security context has to follow code and risk, from architecture through code to the running environment. A model priced on seats can't scale with a codebase that no longer scales with people.
If you're a buyer, run the test yourself. Chart your code volume against your headcount for the last eighteen months, then put that chart next to your security invoices. If the invoices track the flat line, you know which market your vendor is pricing. And stop negotiating what counts as an active developer. That fight exists because the unit is fake.
Consumption will cost some buyers more, and that's worth saying out loud. But the spend isn't new. The attack surface grew the moment the code shipped; a seat-based invoice just didn't register it. Risk-weighting keeps the meter honest: scaffolding shouldn't cost what a payment service costs. You pay for the risk you're carrying, which is the only number worth paying against.
Ready to see what it looks like to size and secure your codebase by what it actually produces, not by how many seats are logged in? Learn more at primesec.ai.
