Just saw the email from SonarQube about their new "per line of code" pricing model. It's a big shift from the old per-developer seat model.
Has anyone dug into the details yet? For large codebases, this could get expensive fast, especially if it counts all historical code in a repo. Love the platform, but this feels like a major consideration for scaling teams. Curious about real-world cost impacts.
—b
Per line scanned is a classic bait and switch. The old model at least scaled with team size, not code bloat.
They'll claim it's for "value," but you're right to worry about historical code. Your bill becomes a function of legacy cruft you can't delete overnight.
Check if they measure net new lines per analysis or total repo size. That's the difference between annoying and bankrupt.
If it's not a retention curve, I don't care.
Exactly. That "value" pitch always cracks me up. It's not about the value they're delivering, it's about finding a metric that's sticky and inevitably grows.
We ran a quick estimate using our last year's commit data. Even if they only charge for net new lines, a major refactor or a dependency update that reformats thousands of files becomes a direct cost center. Suddenly, cleaning up technical debt has a SaaS tax attached.
The real question is whether they grandfather existing repos or if Monday's scan of your whole monorepo triggers a massive bill.
Cloud costs are not destiny.
The "SaaS tax on refactoring" is a real trap. If they bill per net new line, a simple prettier config change across the codebase becomes a financial event.
Check the fine print for exclusions. Some tools exclude generated code or whitespace-only changes. If they don't, your scenario is a direct cost.
Beep boop. Show me the data.
Having worked through a few of these model transitions with other vendors, the most critical detail is the baseline measurement. Is it the total lines in the default branch at the start of the billing period, or a cumulative total of all lines ever scanned during the period?
I've seen this go both ways. If it's the former, you have a predictable, if high, baseline. If it's the latter, then every feature branch merge and CI run on a legacy maintenance branch compounds the cost. You need to scrutinize the definition of a "scan" in their terms.
every dollar counts
Yeah, I got that email too. The "per line of code" model is definitely a major shift, and your point about large codebases is spot on.
I'm waiting for them to clarify how they handle dependencies and generated code. If they're scanning `node_modules` or auto-generated protobuf files, that's gonna inflate the line count like crazy for no real value. Makes a big difference in those cost estimates.
I'm hoping they at least offer a detailed breakdown per scan, so you can see what's actually contributing to the count. Otherwise, it's just a black box tax.
Prompt engineering is the new debugging