Alright, let’s get this party started. I’ve been watching the Mend (née WhiteSource) parade for a while now, and the siren song of “automated open source management” is strong for small teams. Who wouldn’t want to believe the vendor’s promise of a frictionless, secure, and compliant codebase? But as someone who spends too much time knee-deep in SaaS pricing sheets and vendor contract fine print, I’m perpetually suspicious.
So, the question on the table: any hidden costs for a small team signing up? I’ll bet my favorite sarcastic coffee mug the answer is a resounding “of course, but they’d never call them that.” The published pricing is usually a cheerful facade, like a brightly painted door on a blank wall. For a small team, you’re likely looking at a per-developer, per-month model. Seems straightforward, right? Here’s where the fun begins.
First, the definition of “developer” is often elastic. Is it every engineer who touches code? What about DevOps who write pipelines? QA automating tests? That ambiguity is a classic vendor lever. Then there’s the scan volume. Their marketing whispers about unlimited scans, but dig into the terms. Are there thresholds on repository size, frequency, or the number of dependencies pulled? Exceed those, and you’ll hear the gentle whirring of metered billing kicking in.
And let’s not forget the real kicker: the remediation tax. Mend excels at finding problems—congratulations, you now have a backlog of critical vulnerabilities to fix. The “hidden cost” is the developer hours not spent on feature work. Their value prop hinges on you believing their tool saves time, but without disciplined integration and process, it can just become a very expensive, very noisy to-do list. Then there’s the compliance reporting. Need a specific PDF export for your audit? That might be a premium feature. Want to integrate with that niche internal system? Might need a “professional services engagement.”
I’m curious to hear from other small teams who’ve actually gone through the Mend sales wringer. Did the initial quote hold? What did they try to upsell you on once you were in the door? Was the “onboarding” actually included, or did you need a consultant to make it work? I’m bracing for the inevitable chorus of “it’s worth every penny,” but I want the gritty, unvarnished truth. The devil, as they say, is in the details they don’t show you on the pricing page.
—Bella
Price ≠ value.
You're right to be suspicious about that per-developer definition. It's not just about who writes code. In my last gig, we got dinged because they counted anyone with "write" access to a repo with Mend integrations, which pulled in our infra team that manages deployment scripts. That's a cost surge you only see on the second invoice.
And that scan volume point is spot on. "Unlimited" usually means unlimited *initiations*. If you have a lot of small, frequent commits, you're fine. But if your pipeline triggers a deep scan on a massive monorepo with every merge? That's where they might start talking about "fair use" and introduce tiered pricing. Ask them to define a "scan unit" in your contract. If they waffle, you have your answer 😅
ian
That's a critical point about the per-developer definition. Beyond just "write" access, I've seen tools that also count service accounts used in CI/CD pipelines, which are technically "users" in their system. A clear audit trail of exactly who they're counting from your identity provider during the onboarding stage can prevent surprises.
Defining a "scan unit" in the contract is the right approach. If they're hesitant to specify, it's often because the metric is designed to scale with your usage in a way that's not transparent.
Your experience with "write access" as a pricing metric is a perfect example of a failure to align cost with value. The economic model should be tied to the actual unit of value delivery, not an arbitrary proxy like user count. In Mend's case, the primary value is risk reduction derived from scanning a body of code. Therefore, the only truly transparent pricing model would be based on Lines of Code or Number of Dependencies scanned per month. Any model based on user counts, especially one that pulls in non-developer roles, is inherently obfuscated and creates perverse incentives to limit access, which harms operational security.
Regarding scan volume, the distinction between unlimited initiations and unlimited scan units is critical. You need to ask for their internal definition of a "scan job" and get the maximum allowed size and depth in the service description. If a scan of your largest monorepo constitutes a single "job," you're likely safe. If they internally decompose it into thousands of units based on subdirectories or file counts, you will hit a cap. This is rarely documented in the public pricing sheet.
A practical step is to run a proof-of-concept and demand the raw log data of their API calls and scan jobs from that period. Map that data to their proposed billing factors. If they cannot or will not provide this granular consumption data during the trial, assume the worst. Their willingness to expose this mechanics-of-billing data is the true litmus test for transparency.
Data first, decisions later.
Yeah, that "elastic" definition of a developer is what I'm nervous about too. So it can even include QA engineers writing automation scripts? That feels like it could add up really fast for a small team.
How do you even find out their specific definition before signing? Do you just have to ask their sales team directly?
You're right to focus on the scan volume thresholds. The per-developer cost is predictable, even if elastic. The variable scan cost is not.
From our audit: "Unlimited" meant scans under 30 minutes. Our large data transformation repo with deep dependency trees triggered a "performance review" after consistently hitting 45-50 minute scan times. The proposed upgrade was a 40% cost increase.
Always ask for their average scan duration metric across current customers in your size bracket. If they won't share it, assume your largest repo will breach the threshold.
EXPLAIN ANALYZE
You've hit on the crucial operational metric that often dictates the true total cost of ownership. The > "average scan duration metric across current customers in your size bracket" is an excellent request.
A caveat to that approach: even if they provide a number, you need the distribution, not just the mean. Averages can be misleading. If 90% of scans are under 10 minutes but your outlier monorepo sits in the 90th percentile, you'll still trigger the performance review clause. It's more effective to require contractual language that defines the performance review threshold explicitly, in writing, as part of the order form. Something like "Customer shall not be subject to additional fees or forced tier upgrades provided no single scan exceeds X minutes in duration."
Without that, the 'unlimited' claim is functionally meaningless.
measure what matters
Exactly, the distribution is everything. Getting that contractual clause about a specific X-minute threshold is the only real protection. We tried that approach last year and their legal team pushed back hard, saying it "limited their ability to manage platform performance." That pushback itself was a huge red flag about how they intended to use that "performance review" clause.
Our compromise was a softer cap tied to the 95th percentile of our own historical scan times during the trial. It's not perfect, but it created a baseline they couldn't arbitrarily move. Without *some* hard number in the order form, you're just trusting their goodwill.
"Limited their ability to manage platform performance" is just vendor-speak for "we want to keep the leverage." Good on you for forcing the 95th percentile baseline.
Even that has a trap, though. They can just slow down the scans during your trial period to set a lower bar. You need to audit the trial logs yourself with a separate timer.
Without that, your baseline is fiction.
You're totally right about that "brightly painted door" feeling. I had the same suspicion when we trialed it last quarter.
That "developer" definition got us too. We found out their plugin in our IDE counted *anyone* who ran the local scan action, even our designer checking for icon licenses. That's not in the marketing copy.
And yeah, unlimited scans until you connect your massive legacy project. Then it's time for a "platform performance chat." Ask for their scan time distribution data *before* the trial. If they won't give it, you know how that story ends.
If it can be automated, it will be.