saas — jd:/dev/blog

The SaaSpocalypse Won't Kill SaaS

Tue, 31 Mar 2026 00:00:00 GMT

A reader emailed me last week. He'd listened to a podcast I did on saas.group about selling developer tools, and he had a question I've been hearing a lot: how do you pitch SaaS when the cost of building software is collapsing?

Source: TechCrunch

Fair question. In January 2026, Anthropic launched Claude Cowork, and Wall Street panicked. Roughly $300 billion in SaaS market cap disappeared in a single trading session. Wall Street analysts coined a term for it: the SaaSpocalypse. Per-seat pricing? Dead on arrival, apparently.

The "I can build that" crowd finally has data on their side. They're right about one thing, and wrong about everything else.

"I Can Build That"

I've been hearing this for seven years. From the very first Mergify demo, developers would look at our merge queue and think: "This is just an automatic rebase, right?" Twenty minutes later, after walking them through race conditions, speculative merging, priority queues, and a dozen edge cases they hadn't considered, the reaction would shift: "Oh. That sounds quite hard to do." (I wrote about this back in 2024, and every word still applies.)

AI has made the objection louder. A developer with Claude or Cursor can now scaffold a basic merge queue in a weekend. I know this because I've done it myself: I shipped a production feature at Mergify using AI, coding less than an hour a day. But I could do that because I had seven years of context telling me what to build and how to evaluate the output. The AI wrote the code. The judgment about what code to write came from running the product.

A competitor starting from scratch with the same AI? They'd build the wrong thing. And that's the part nobody talks about at the end of the vibe-coding weekend: you're not done. You're at the starting line. You've compressed the first sprint, not the product. It's not done until you have real users running real workloads. Until you have a team that can maintain what you built. Until you can evolve it for years. The weekend prototype doesn't know that GitHub's API is asynchronous in ways they don't document, that it breaks under load in ways you only discover at scale, or that the enterprise customer needs SAML before they'll even look at your product.

Building Is the Easy Part

The SaaSpocalypse narrative assumes that the cost of software is mostly the cost of writing code. It's not. Writing code was always the cheapest part.

Source: Retool

Retool's 2026 Build vs. Buy report says 35% of enterprises have already replaced at least one SaaS tool with a custom build. That's a real number. But the report also shows where the replacements are concentrated: workflow automations, internal admin tools, basic dashboards. The easy stuff. The tools that were always one ambitious intern away from being replaced. I don't see enterprises vibe-coding their own Salesforce or Datadog.

The costs that AI didn't make cheaper:

Users. Finding them, understanding what they actually need (not what they say they need), and iterating based on real usage patterns. We built speculative merging at Mergify because a customer running 100+ PRs a day showed us that sequential merging broke down at scale. That insight came from watching real teams hit real walls, not from a prompt. No model can replicate that feedback loop yet, because it requires deployed software, real usage data, and the kind of trust that makes customers tell you what's actually broken.

Maintenance. Your weekend project works today. Will it still work when GitHub ships a breaking API change? When your company scales from 50 to 500 engineers? When the on-call engineer at 2am needs to debug a failure path you never tested? AI makes writing code faster, but it hasn't made maintaining it any easier.

Trust. Enterprise buyers don't want a git repo. They want SOC 2, uptime SLAs, a support contract, and someone to call when things break. Trust is earned across hundreds of deployments, not generated in a prompt.

The Real Moat Is Not Code

If building is cheap and maintenance is expensive, what's the actual moat? Domain expertise. The thing that takes the longest to build up and is the hardest to transfer.

Product discovery is the boring work that separates a tool from a product. The thousands of conversations with users. The wrong turns that taught you what not to build. The instinct for when a feature request is actually a symptom of a different problem. Seven years of running Mergify gave us knowledge that doesn't fit in a markdown file (or a Claude skill, at least not yet).

Reliability, trust, and ease have no price. They're earned over years, not generated over a weekend.

AI agents are getting better at learning domains. METR benchmarks show that the scope of what AI can handle autonomously is doubling roughly every seven months. I'm not dismissing that. But domain expertise isn't just knowledge you can look up. It's judgment shaped by consequences. AI can read your docs. It can't feel the pain of shipping a bad feature to 2,000 teams and spending the next month cleaning up the fallout. That scar tissue is what makes you build differently the next time. Maybe AI will get there. But right now, there's no shortcut to the operational context you accumulate by running a product for years.

Natural Selection

None of this means every SaaS company is safe. Thin wrappers, glorified CRUD apps, tools that existed only because building was expensive: they should be worried. This is natural selection, and it won't be fair. Some decent products with real value will die too, because their surface area is small enough for AI to replicate. A standalone CSV-to-dashboard tool? That's a Claude prompt now, not a business.

Source: TechCrunch

Benioff says "this isn't our first SaaSpocalypse." He's right that SaaS survives, but he's wrong to be dismissive about how many won't.

The SaaSpocalypse narrative confuses the death of lazy SaaS with the death of SaaS. The model isn't dying. The bar is rising. The products that survive will be the ones where the code was never the point. The point was always the knowledge embedded in it.

The Pitch Hasn't Changed

Back to my reader's question: how do you update the sales pitch?

You don't. The pitch was never "we wrote the code so you don't have to." It was always "we know things you don't, and we turned that into a product you can trust." The framing shifted. Instead of "look at all the edge cases you'd have to handle," it's now "look at all the edge cases AI doesn't know exist."

The moat was never the code. It was always the knowledge.

SaaS Pricing is Hard

Tue, 04 Feb 2025 00:00:00 GMT

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.

If you want more on how we think about pricing, I wrote about why we're sticking with seat-based pricing over work-based models and the broader build vs buy dilemma from the customer's perspective.

SaaS and Work-based Pricing

Tue, 19 Nov 2024 00:00:00 GMT

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. I wrote more about our full pricing journey at Mergify — from copying GitHub's model to active user billing.

Solving Build vs Buy

Tue, 13 Aug 2024 00:00:00 GMT

Selling to developers is challenging, and the mindset of “build or buy” is one of the biggest hurdles. Over the past year at Mergify, we've encountered countless engineers grappling with this dilemma.

Developers are natural problem-solvers. When they encounter an issue, their first instinct is often to build a solution themselves. They see a problem, identify it, and immediately start imagining how they would solve it. However, there's a significant gap between having expertise in engineering and having expertise in a specific solution.

The Overconfidence Trap

Many developers fall into the trap of underestimating the complexity of the problems they're trying to solve. It's akin to asking an engineer, "How long to fix XYZ?" and hearing, "Should be done today," only for the task to stretch out over a week as unforeseen complications arise. They start working on the problem, only to discover layers of hidden challenges—refactoring needs, unexpected dependencies, and more. It all makes sense in hindsight, but it's nearly impossible to foresee these issues at the outset.

This overconfidence often leads to the creation of subpar solutions. While some teams might eventually succeed, these homegrown solutions fall short of their commercial counterparts more often than not. Moreover, solving problems outside of your core business usually results in a poor return on investment. Think about it: how many companies still manage their own email servers when GSuite offers a hassle-free solution for just $6 per user per month? Your IT team is incapable of competing with such an offer.

The typical customer for this comes to your demo call with a speech along those lines: “We’ve tried building a solution to this problem, but we failed because we hit too many bumps in the road; it seems you guys know how to solve it.” Teams that take this road are the easiest to win customers because they already know they can’t build.

The Build or Buy Mindset in Action

During our demo sessions at Mergify, we frequently encounter engineers who are initially skeptical about buying a solution. They come with a build-or-buy mindset, confident in their ability to solve the problem themselves. They're curious about why they should spend money on a product when they believe they can build it in-house. This is where it gets interesting.

One of the most enjoyable aspects of these sessions is debunking their assumptions. For instance, many engineers approach our merge queue system thinking, "This is just an automatic rebase, right?" After a 20-minute demo, they often leave with a new appreciation for the complexities involved. "Oh, okay. That sounds quite hard to do. Good job." This is where I reply with: “Well, this is why we’ve been working on this for 5 years already and have hundreds of customers.” 😉 Let me brag a bit.

By walking them through the numerous edge cases and intricacies that our product handles, we can show them just how challenging the problem really is.

The Power of Demonstrating Value

This experience highlights why startup founders who are engineers can be excellent salespeople. They understand the technical mindset and can effectively communicate the value of their products. The key is to convey the value of your product in your messaging and demos.

Having at least one feature that is both highly valuable and challenging to implement can make a significant impact. The more features like this you can demonstrate, the better—provided they solve real problems and aren't just complex for complexity's sake.

Final Thoughts

The "build or buy" dilemma is a significant barrier in marketing devtools. Developers' natural inclination to build solutions themselves can lead to underestimations of complexity and overconfidence. By demonstrating the intricate challenges your product solves and highlighting its value, you can shift their perspective. In the end, it's about showing that your solution is not just a convenience but a necessity for efficient and effective problem-solving. Once you've won them over, the next challenge is getting pricing right — which has its own set of hard lessons.