Spot on about the post-pilot price jump. That's a classic "gotcha" that can turn a successful pilot into a rushed, high-pressure renewal.
Beyond just asking for the breakdown, I'd suggest asking them to attach the negotiated pilot rate directly to your "success criteria" document. If you hit your agreed adoption metrics during the pilot, the price shouldn't just be honored, it should be the starting point for the next conversation.
What did you end up using as your success metrics for those 10 critical repos?
—HR
Per repo is better than per dev, but it's still a trap. You'll be fighting over what counts as a "repository" forever. Is it a monorepo with 50 microservices? That's 50 repos to them.
A cap on repo count growth is meaningless if the base price per repo jumps 300% at renewal because you're now "locked in."
The only clause that matters is the one that kills auto-renewal. Get it in writing.
show me the bill
> But I've heard the pricing can be... intense for growing startups.
That's the whole game. They get you to pilot the shiny toy, then the real invoice hits at renewal. The playbook is to ignore their list price entirely. It's fiction.
If you're new to this, starting with container scanning is a perfect way to waste six months and blow your budget. You'll be paying them to tell you about CVEs in the alpine:latest base image you can't fix. Start with the CLI for open source, see if your team actually uses it, then maybe talk money. If you skip that step, you're just buying a fancy dashboard nobody looks at.
If it ain't broke, don't 'upgrade' it.
Per repo is a fine idea until they redefine what a repo is. I've seen them try to bill each branch as a separate "environment" on renewal.
That cap on repo growth is pointless if the underlying per-repo cost isn't locked for the entire term. They'll give you the 20% cap, then just double the price per unit. You need the fixed metric AND the fixed price, not one or the other.
Committed pricing only works if the cancellation clause has real teeth. Otherwise they'll just jack the rate and dare you to eat the migration cost.
If it ain't broke, don't 'upgrade' it.
The per-repo price and the 20% growth cap are the easy part to get on paper. The real gotcha is in the definition they'll bury in the exhibit or MSA. You need to pin down, in the same signed order form, exactly what constitutes a "repository" for counting purposes. Is it a GitHub repo? Does a monorepo count as one, or do subdirectories with separate package manifests become billable units? Get that definition locked in writing next to the price metric. Otherwise, the cap is worthless because they'll just expand the definition at renewal to capture more units within your "capped" count.
Automate everything. Twice.