Why we price on your revenue, not your seats

Every serious pricing conversation Collins and I had in the first year came back to the same contradiction.

We were building a product whose entire premise is that revenue problems cross teams — that a churn spike needs marketing, product, support, and finance in the same room. And the default SaaS pricing model would have charged our customers more every time they invited one of those people.

You cannot sell cross-functional collaboration and then put a toll booth on the third function.

So we price per company, on a band determined by your annual revenue.

The pricing, stated plainly

Annual billing takes 10% off. Transactional messaging is usage-based on top: $2 per thousand emails, $20 per thousand SMS, $25 per thousand WhatsApp.

Unlimited users at every tier, including Free.

Why seats are the wrong meter

A pricing meter is a statement about what you think creates value. Per-seat says value scales with the number of people using the software.

For most tools that's roughly true. For this one it's backwards.

The value of a Room goes up when the engineer who shipped the change is in it. It goes up again when the support lead who's been reading the tickets joins. It goes up again when finance confirms what the discount policy actually is. Every additional relevant person makes the diagnosis better — that's not a side effect of the product, it's the mechanism.

Charging per seat would mean a growth lead doing mental arithmetic before adding a colleague to a diagnosis. Some of them would decide the marginal seat wasn't worth it, and they'd be making a locally rational decision that degrades the thing they bought.

Causal finding this one is definitional rather than empirical. If the product's value derives from cross-functional participation, and the price rises with participation, the pricing model is in direct opposition to the product's value mechanism. That holds regardless of what the price level is.

Why revenue is the meter instead

Three reasons.

It tracks what's at stake. A company doing $40M has vastly more revenue at risk from a two-point repeat-rate drop than one doing $2M. The leak is the same shape; the money is an order of magnitude apart. Pricing on revenue means what you pay is roughly proportional to what a fix is worth.

It tracks the work. More revenue generally means more customers, more transactions, more markets, more sources, more agent runs. Cost to serve broadly follows revenue, so the meter is defensible from our side too.

It's legible. You already know your annual revenue. You don't have to forecast monthly active users or data points to predict your bill, and you don't get a surprise at renewal because a metric you don't control moved.

What it costs us

Four real problems. I'd rather name them than let you discover them.

We leave money on the table with large teams. A 300-person company on Scale pays the same $6,000 as a 30-person company on Scale. Per-seat would extract substantially more from the first one. We've accepted that.

Revenue bands create cliffs. A company at $4.9M pays $2,500. At $5.1M they pay $6,000. That's a 140% increase for 4% growth, and it's genuinely unfair at the boundary. We handle it case by case at renewal rather than pretending the cliff isn't there, and I'm not satisfied that's a real solution.

It requires customers to disclose revenue. Some find that intrusive, particularly private companies. We take a stated band rather than audited figures, which means we're trusting people — and occasionally being wrong about it.

It's a weak meter for unusual businesses. A high-revenue, low-margin business — some marketplaces, some resellers — pays a band that overstates their capacity relative to a high-margin SaaS company at the same top line. We adjust for these manually. That's not a system, it's a patch.

Why the Free tier is real

Free is under $500K in revenue, and it includes one workspace, two data sources, two AI agents, three active Rooms, basic lifecycle and segments, one campaign a month, and 500 messaging credits.

It isn't a trial with an expiry. Two reasons.

The first is honest self-interest: Business Memory compounds. A workspace that's been running for eight months has resolved Rooms, validated learnings, and agents tuned by real outcomes. That's worth more to the customer than the same workspace on day one, and it's worth more to us as a retention asset. Time is the input we most want to give away.

The second is that a company under $500K in revenue genuinely can't afford $2,500 a month, and they have the same leaks. Making them wait until they can afford it means they arrive with two years of undiagnosed decay baked into their cohort curves.

The parts I'm least sure about

Messaging on top might be a mistake. It's a second meter with a different logic, which cuts against the legibility argument I made above. It exists because messaging has genuine marginal cost we can't absorb at volume. But a customer who understood "one price per company" is now watching two numbers, and I take the criticism.

The Free-tier Room limit is arbitrary. Three active Rooms was a guess. It might be the wrong constraint entirely — capping Rooms caps exactly the behaviour we want to encourage. Data sources might be the better ceiling. We're watching whether Free workspaces hit the Room cap and stall or hit it and upgrade, and we'll change it if the answer is stall.

Enterprise is "from $15,000" and that's vague. It's vague because the work varies — data residency, custom agents, white-labeling, dedicated onboarding. I'd rather quote honestly per situation than publish a number we'd deviate from in every deal, but I recognise "contact us" is the answer nobody enjoys.

What we'd change if we're wrong

The strongest argument against revenue-banding is that revenue is a lagging indicator of a company's ability to pay. A business that's just raised and is deliberately unprofitable has more capacity than its revenue suggests. One that's contracting has less.

If we find that bands consistently misprice a recognisable class of customer, the honest fix is another dimension — probably connected data sources or agent runs, which track work more directly. We haven't done it because two meters are already one more than I want.

What we won't do is move to per-seat. That one isn't a pricing question. It's a product question, and the answer is no.