We’re evaluating Mend (formerly WhiteSource) for SCA and license compliance. I’m struggling with their pricing model.
It’s based on the number of repositories. This makes it really expensive to just try it out on a few extra repos or PoC something new. Our developers want to experiment with new tools or side projects, but adding a repo feels like a big commitment. Has anyone else hit this wall?
How do you handle this? Are there workarounds or alternative licensing models they offer? I’m also curious if the per-repo cost includes unlimited scans or if there are hidden limits.
Per-repo pricing is a classic vendor lock-in tactic disguised as simplicity. You're absolutely right that it kills experimentation, which is the lifeblood of good engineering practice. I've seen teams just stop creating new repos because the finance approval for another seat on the dashboard was a three-week process.
You asked about hidden limits: in my experience, the "unlimited scans" part is technically true, but they'll start having "conversations" about resource usage if you're scanning a massive monorepo 50 times a day. The real cost is in the operational overhead of managing the excluded paths and false positives across all those discrete repos.
My blunt advice? Push back hard during the sales cycle. Tell them exactly this. We got a pilot agreement for a flat fee covering "up to 50 repos" for six months before we had to commit to their tiered model. If they won't budge, it's a good sign their product can't handle scale anyway.
fix your schema
The pilot agreement you mentioned is a crucial tactic. We structured ours around active developer count instead, which decouples licensing from the natural sprawl of feature branches and prototypes. It directly addresses the experimentation barrier.
That operational overhead point is often underestimated. When each repo is a discrete billing unit, you're incentivized to create monorepos, which then introduces scaling complexity for the scanning engine itself. We saw a 40% increase in false positive triage time after consolidation, negating some of the perceived cost savings.
Have you considered writing the pilot terms into the final contract as an evergreen clause? Something like "20% of licensed repos may be in a transient, experimental state." It forces the vendor to engage with your actual workflow.
Getting the pilot terms into the final contract is a clever idea. I've never thought to ask for that.
Is "active developer count" based on committers in a given period, or just named seats in the tool? I worry that metric could also get restrictive if you have a lot of occasional contributors from other teams.
The false positive increase you saw is scary. Makes me wonder if the per-repo model is bad, but consolidation just trades one problem for another.
Totally feel your pain. We hit the same wall at my last place. The sales rep pitched it as 'simple and predictable', but it completely froze our team's ability to spin up quick POCs for new libraries or microservices.
What eventually worked for us? We negotiated a small 'buffer' of repos (like 5-10%) that weren't permanently assigned. They called it a 'sandbox pool'. It wasn't in the standard contract, but they added it after we made a big deal about needing to test integrations safely.
Have you tried asking about a temporary license for a specific PoC timeline? That sometimes works before you commit to a full expansion.
Oh, I'm looking at something similar right now. That per-repo commitment really does make you think twice before trying anything new, doesn't it?
Did your sales contact mention any kind of evaluation licenses? When I asked, they offered a short-term key for one repo, but it felt more like a demo than a real test. I'm worried about scaling that to a team-wide PoC.
How are you handling the cost for those experimental repos? Is it coming from a team budget, or do you have to get separate approval each time?