I run Drumbeats — a cron and uptime monitoring service. A few weeks ago I removed seat caps from every plan, including the free one. This post is not really about that change. It is about the pricing decision I kept avoiding for months, and why I think per-seat pricing is quietly the worst default in B2B developer tools.
The uncomfortable thing about per-seat pricing
Per-seat pricing has one honest virtue: it scales revenue with the size of the customer. A 200-person company pays more than a 5-person team. That is fair, and it is why every investor deck has it.
It also has one deeply dishonest consequence that nobody likes talking about: it makes your customers ration access to the tool they are paying you for.
You have seen it. I have done it. The VP looks at the invoice, sees $8/user/month across 40 seats, and asks "do we really need all of these people on it?" And the answer — for a monitoring tool, an observability dashboard, a staging environment, an internal admin — is almost always "yes, but we can make do with fewer."
So teams make do. The on-call engineer who joined last month does not get added because it would bump the plan tier. The junior who is learning the system gets a shared login. The stakeholder who genuinely needs visibility into deploy health ends up DMing a teammate for screenshots.
The tool that is supposed to give your team visibility into production becomes the tool your team routes around.
What the numbers actually look like
Here is the math I kept running. Take a monitoring tool at the Cronitor-style rate of $5 per user per month on paid plans. A 10-person engineering team:
- 10 seats × $5 = $50/month in seat fees
- Before a single monitor, alert, integration, or feature is paid for
That 10-person team is not the customer anyone is pricing for. The pricing page is designed for the 200-person org where $5 × 200 = $1,000/month is rounding error next to the Datadog bill. The 10-person team is the one feeling every dollar of it.
And that 10-person team is me. And probably you.
When I sat down to design Drumbeats' plans, every per-seat model I sketched did the same thing: it priced out the exact customer I was trying to serve.
Three bad alternatives I considered
Before landing on unlimited, I worked through the usual escapes:
1. Per-seat with a "starter team" free tier. Standard SaaS pattern. The problem: the free tier becomes the onboarding experience, and the onboarding experience is "you will hit a wall." Users who run into the wall on day 2 never become customers on day 30.
2. Tiered seat caps by plan (5 / 25 / 100). This is what I actually shipped originally. It was fine. But every plan is now a negotiation between "the monitoring I need" and "the seats I need," and those two things have nothing to do with each other. A 2-person team can have 500 monitors. A 30-person team might have 20 monitors but want everyone notified on deploys.
3. Free read-only seats, paid write seats. Elegant on paper. In practice it is a support burden: customers cannot figure out why Alice can acknowledge an incident and Bob cannot. The cognitive overhead leaks.
None of these solved the rationing problem. They just moved it.
What I actually shipped
I removed seat caps from every plan. Free, Pro, Business — all unlimited. Invite your whole team, no per-seat fee, no counter ticking up in the corner of the settings page.
Pricing is now based on what the product actually consumes: checks, requests, monitors. The things that cost me money to deliver. Not the number of humans looking at the dashboard.
Revenue still scales with company size, because bigger companies run more monitors and generate more checks. But it scales with usage, not with headcount politics.
The objection I have heard
"What stops a huge company from creating one account and having 500 people share it?"
Nothing. I am fine with it. If that company is running a usage volume that justifies a Business-plan subscription, I am already being paid appropriately. The number of humans inside their Slack workspace is genuinely not my business.
The other objection — "but enterprise buyers expect per-seat line items for their procurement process" — is a real one. My answer is that I am not selling to enterprise procurement today. I am selling to the engineer who needs a monitoring tool that will not punish them for inviting a teammate. When I get to the enterprise stage, I will figure that out then.
The honest tradeoff
Removing seat caps reduces one lever I had for driving upgrades. A team that would have upgraded from Free to Pro purely to get more seats will now stay on Free longer.
I accepted that. The alternative — that the people who actually need the tool cannot use it — is the worse business outcome, even if it looks better in a cohort chart for a quarter.
If you are designing pricing for a developer tool right now, my suggestion is: price the thing your product costs you to deliver. Do not price the humans in the room.
What is the worst per-seat pricing experience you have had as a buyer — the one that made you churn or never adopt? I want to hear the specific examples.
Full post with the changelog framing and tables:
https://drumbeats.io/blog/unlimited-team-seats-on-all-plans
Top comments (0)