Stop charging per seat (your AI agents don't have butts)
You built a SaaS. Ten customers, each paying for ten seats. Business is good. Then one of them calls and says, "Hey, we replaced eight employees with AI agents. Can we downgrade to two seats?"
That's an extreme scenario, but it shows the problem: your revenue could drop dramatically even though your product is working exactly as intended. And it raises a question that goes beyond pricing — if customers are replacing most of their team with AI agents, that's not just a line-item issue for SaaS founders. It's a shift with real consequences for the people whose jobs disappear, and we shouldn't talk about it purely in terms of revenue math.
The seat compression problem
This trend is emerging from multiple directions. A recent Retool survey (2024) found that 35% of their users have already replaced at least one SaaS tool with custom-built internal applications. 78% expect to build more in 2026. That's not the same thing as AI agents directly replacing seats — it's about teams building their own tools instead of buying off-the-shelf SaaS — but it signals the same underlying pressure: the assumption that more humans means more seats means more revenue is weakening from multiple angles.
The math is uncomfortable. If you're charging per seat and your customer's "team" is now two humans and several AI-powered automations, you have a pricing model problem. Not a product problem. A math problem.
I noticed this with my own stack first. I was paying for three seats on a project management tool. Then I set up an AI agent that handles triage, updates, and status reports. Suddenly I'm the only one who actually logs in. The tool still works. It's still useful. But the pricing model assumes humans sitting in chairs, and my agents don't have butts.
Three pricing models that actually work
I've been watching companies navigate this shift, and three approaches keep working:
Consumption-based (the Snowflake model)
Charge for what gets used. API calls, processed items, storage, compute time. The beauty of this is that it scales with agents. An AI agent that makes 10,000 API calls per day pays more than a human who logs in twice a week. Your revenue goes up when automation goes up.
Twilio has done this for years. You don't pay for "seats" on Twilio. You pay per SMS, per minute, per API call. When a company hooks up an AI agent that sends 50,000 verification texts a day, Twilio doesn't care that no human pressed "send." Revenue scales with usage, not headcount. Vercel does the same with compute. So does Stripe with transactions. The model isn't new. What's new is that it's becoming the only model that makes sense.
Outcome-based (pay per solved problem)
This is the spicy one. Instead of charging for access, charge for results. Per resolved support ticket. Per successfully processed transaction. Per generated report.
HubSpot is doing something similar with "HubSpot Credits" — a consumption unit that decouples pricing from humans-in-seats. It's more accurately described as consumption-based than outcome-based, but the principle is similar: decouple price from headcount.
For indie devs, this is actually easier to implement than it sounds. Say you built a tool that generates weekly analytics reports for small e-commerce shops. Instead of charging per seat, you charge per report generated — whether the shop owner clicks "generate" or their AI agent triggers it via API at 6 AM every Monday. You already know what your product does. Count those things. Charge for them.
Hybrid (base + usage)
The pragmatic middle ground. A base subscription gets you the platform, the data storage, the integrations. Then you pay for usage on top. It's predictable enough for customers to budget, flexible enough to survive the agent revolution.
This is where I'd start if I were building a new SaaS today. Low base fee, generous free tier, then charge for the things that actually cost you money to provide.
What this means if you're building right now
Stop building "lazy SaaS." If your entire product is a thin wrapper around a database with a nice UI, you're increasingly vulnerable. AI tools are getting better at generating interfaces quickly, though there's still a meaningful gap between a generated prototype and a reliable, tested, maintained product. Your moat needs to be deeper either way: integrations, compliance, data quality, workflow-specific logic.
Make your product agent-friendly. Add an MCP server. Seriously. MCP is showing up in more places, and if an AI agent can't talk to your product, your product risks becoming invisible in an increasingly agent-driven economy. I wrote about this before — the trend has only accelerated.
Price for value, not for presence. The question isn't "how many people use your product?" It's "how much value does your product create?" If your tool processes 1,000 invoices, it doesn't matter if a human or an agent submitted them.
Don't panic. SaaS isn't dying. The SaaS market is still experiencing strong growth, with projections reaching over $400 billion by 2026. What's dying is the assumption that every user is a human with a butt in a chair. Adjust your pricing, keep building, and you'll be fine.
The uncomfortable truth
Per-seat pricing persists because it's the easiest model to implement. users * $29/month = revenue. Clean. Simple. Fits in a spreadsheet.
But easy isn't the same as durable. And right now, every indie dev building a SaaS has a choice: adapt the pricing model now while it's a strategic advantage, or adapt later when survival depends on it.
I'm a developer who went from .NET to Laravel to building with AI agents full-time. I write about what actually works — and what doesn't.
Get my weekly takes on vibe coding, AI-assisted development, and building products as a solo maker.
