SaaS and Work-based Pricing
Is this the future?
Despite the rising popularity of work-based pricing in SaaS, Mergify is sticking with seat-based pricing—for now. Here’s why we believe it’s the right choice for our product and our customers, and their ability to budget with confidence
The Work-Based Pricing Trend
Following the latest SaaS pricing trends is tempting, especially when they align so well with a powerful concept: customers pay in proportion to the value they receive. In recent months, “work-based” pricing has gained traction across the industry, especially in AI-driven applications where you pay per task completed. It’s a straightforward exchange: resolve a customer’s problem and receive $1.
Simple, clear, and highly attractive.
When we first considered revisiting Mergify’s pricing for next year, work-based pricing seemed like a model worth exploring. Imagine a setup where every task accomplished by Mergify correlated directly to the value we delivered to our customers. More value equals more payment, a transparent exchange that clients find easy to understand. But, as we dove deeper, we realized that the nature of Mergify’s work doesn’t fit so neatly into this model.
And that might be true for your SaaS as well.
The Value Clarity of Work-Based Pricing
Work-based pricing makes perfect sense for certain SaaS products. Consider the AI-driven customer support solutions rolling out recently, like Salesforce’s $2-per-conversation approach or Intercom’s Finn and its 0.99$ per resolved conversation. The pricing here is inherently appealing because it aligns precisely with the customer’s perception of value: for every problem resolved, they see a clear, direct benefit to their end users, who leave satisfied and engaged.
This clarity makes it easy for a customer to decide—they’re paying to solve a specific pain point for their users, and each solved interaction has a measurable outcome. The more conversations are solved, the more they pay; it feels like a no-brainer.
Customers see exactly where their money is going, and it scales beautifully alongside their growth: the more users they have, the more problems they have, and the more value you can provide. But also: the more users they have, the more money they have, so they’re happy with giving you a part of it. Everything can grow at the same rate, from the customer’s business size to the value your SaaS provides.
This reminds me of the early days of cloud computing when Amazon Web Services introduced usage-based billing. The more your business grew, the more infrastructure you used, and the higher the bill. It made perfect sense, and that was one of the reasons for its success and early adoption by startups.
Why Work-Based Pricing Doesn’t Always Fit
At Mergify, we aimed to find the same direct correlation between our value and our pricing model. However, our reality is different: the value we provide is primarily to software engineers who use Mergify to streamline their CI/CD workflows. It’s an incredibly powerful tool, but it doesn’t impact our customers’ end-users in an obvious way. This makes work-based pricing challenging because we’re one step removed from the end-user experience — and, therefore, from the business.
We brainstormed possible approaches. Perhaps we could charge per pull request made by developers. After all, that’s a major part of what Mergify automates and where it provides value. But we immediately saw a problem: this model could encourage the wrong behavior. If every pull request carries a charge, teams might try to reduce the number of pull requests to save on costs, potentially compromising code quality. As engineers ourselves, we value clean, atomic commits and easy reviews. A per-pull-request charge could discourage these practices, creating friction between the optimal workflow and our pricing model.
Another challenge with work-based pricing is the difficulty it presents for customers when predicting their usage. Most organizations set budgets a year in advance, and it’s nearly impossible for a team to accurately estimate the number of pull requests or jobs they’ll need in a year. This unpredictability makes budgeting stressful and challenging, especially for engineers seeking approval for software expenses. With seat-based pricing, customers know their costs upfront, which aligns much better with annual budget planning.
We also considered a per-job charge based on CI (Continuous Integration) runs, but this quickly ran into similar issues. Running a high volume of CI jobs often results in better software quality. Charging per job could lead to reduced testing—a problematic incentive in an industry where quality matters deeply. CI providers charge per job because of the required computing power, but in Mergify’s case, we don’t incur comparable costs. So, a per-job charge wouldn’t reflect our real costs and could end up discouraging best practices.
The Challenge of Finding the Right Fit
In a perfect world, we’d find a model where Mergify’s pricing scaled directly with the customer’s perceived value. However, we found that our usage patterns, like many SaaS, do not align with the benefits of the work-based approach. To truly capture the value Mergify provides, we realize that seat-based pricing continues to be our best option, at least for now.
By charging per user (seat), we avoid influencing developer behavior, allowing them to use Mergify to improve their workflow without second-guessing how often they use it. We also want to avoid the stress of unpredictable costs. Seat-based pricing allows our clients to budget accurately and avoid unexpected expenses, aligning our pricing model with their planning cycles and offering peace of mind. As we continue to build Mergify, our goal remains to be the trusted tool in the hands of developers.
Right now, that means a seat-based model, which keeps our focus where it belongs—on supporting teams to do their best work, no strings attached.
This decision wasn’t easy, and we might revisit it in the future. Pricing is a delicate balance between the customer’s experience, the product’s value, and the company’s needs.