Pricing is one of the hardest things to get right in SaaS. If you’re a startup founder, especially in B2B, you’ve likely wrestled with pricing questions:
💰 How much should I charge?
📊 What pricing model makes sense?
⚖️ How do I ensure fairness while maximizing revenue?
At Mergify, we’ve spent years experimenting, iterating, and learning the hard way. Here’s a breakdown of our journey—and what we’d do differently if we had to start over.
How We Picked Our First Pricing Model
When we first launched Mergify, we had no idea what the right pricing model should be. So, like many startups, we copied GitHub.
We charged per user, based on the size of the entire organization.
This meant that if a company had 200 engineers, they had to pay for all 200 engineers—even if only 20 or 30 of them actually used Mergify.
For small companies (e.g., 20–30 engineers), this wasn’t a big deal. They usually had one team using Mergify across all their repos. But as we grew and larger companies came in, things got tricky.
🛑 Larger companies had multiple teams, and only some teams used Mergify.
💰 They didn’t want to pay for everyone—just for the engineers who actually needed it.
We needed to change.
Counting Users the “Right” Way
To address this, we moved to a new model:
✅ Instead of charging per organization, we charged per collaborator—engineers who had write access to a repository where Mergify was active.
This felt fairer. A company with 100 engineers could now pay only for the repositories where Mergify was used, rather than for the entire org.
At the same time, we doubled our price per user. Why?
Customers were already seeing the value, and price wasn’t their biggest concern.
The new model lowered the user count for most companies, so we had to balance revenue.
The Math: Why This Worked
For a company with 100 engineers:
Old model: $2 per user × 100 users = $200/month
New model: $4 per user × 50 repo contributors = $200/month
For many customers, their bill stayed roughly the same. But they were happier because they felt they were paying for what they actually used.
Fairness is Everything
But the journey didn’t stop there.
Larger organizations often gave write access to all engineers by default, even if only a subset was actually making commits. That meant some companies were being charged for engineers who weren’t actively contributing.
So we introduced another iteration:
✅ Charging per “active user”—engineers who actually made commits.
This approach, inspired by Slack’s active user model, made more sense. Now, companies only paid for users who actively used Mergify.
The Math: Why This Worked (Again)
For a company with 100 engineers, where only 40 engineers actively pushed commits:
Previous model: $4 per user × 100 write-access users = $400/month
New model: $8 per user × 40 active users = $320/month
Again, the price per user increased, but total spending often decreased or stayed the same. More importantly, it felt fairer to customers.
The Real Takeaway: Fairness > Exact Pricing Models
What we’ve learned is that most customers don’t scrutinize how much they pay—but they deeply care about why they are paying it.
💡 Customers want fairness more than they want cheap pricing.
They don’t want to pay for people who never use the product.
They want transparency in billing.
Now, no matter how much we refine our pricing, some customers will always question it. That’s fine. What matters is that we keep the discussion focused on value—not just pricing mechanics.
Advice for SaaS Startups Navigating Pricing
Don’t get stuck in the weeds of perfect pricing.
Focus on maximizing total revenue, not obsessing over per-user logic.
Price increases aren’t scary if you frame them well.
Every time we changed how we counted users, we also raised prices—and it worked fine. You can always grandfather happy customers.
People care more about fairness than numbers.
If customers understand why they’re paying what they’re paying, they’re much less likely to complain.
Final Thoughts
Pricing is a constant work in progress. We’ll probably keep refining it at Mergify as we grow. But the core lesson is this: be transparent, focus on fairness, and anchor pricing to the value your product delivers.
Are you struggling with SaaS pricing? Let me know—I’d love to hear your thoughts and lessons learned.
Really good piece. Here are some of my own ramblings on startup pricing to add to the dialogue. to your point on getting to fairness, i've personally found that willingness to pay is a great tool for founders to better understand how their market thinks about what is fair for the value, vs what is prohibitive, etc. https://fynn.substack.com/p/startup-pricing
Thanks Julien, once again a great feedback. At Kotzilla we decided to count active users as well.
Each new user added comes with a data quota which is supposed to cover his own usage, at development stage. I believe it brings predictability, which is super key on a pricing model based on users AND data.
The thing to avoid is a (bad) surprise right from the first invoice IMO.
So fairness + predictability (which is linked ofc)