There's already a post on this site about pricing a fixed-scope automation project — that's a one-time negotiation between a freelancer or agency and a client with a defined deliverable. This is a different question. This is about the recurring pricing structure of a product itself: the thing a customer sees on a pricing page and decides to pay every month, or every time they use it, for as long as they keep using it.
Engineers who've never priced a product tend to treat the choice as a single dial — cheap versus expensive — when it's actually a filter. Flat, per-seat, usage-based, freemium and outcome-based pricing each select for a different kind of buyer and reward a different kind of customer behavior. Getting that selection wrong shows up later as a revenue problem that looks like a marketing problem, which is exactly the kind of misdiagnosis spends a lot of its own writing untangling for growth teams. If pricing models for a technical product, compared needs to survive contact with a marketing team, has the operational side. If pricing models for a technical product, compared needs to survive contact with a marketing team, the team at XenGrowth has the operational side.
Per-seat: bets that more people equals more value
Linear charges $10 per user per month for its Basic plan and $16 per user per month for Business, billed annually, on top of a free tier. Notion runs the same shape — $0, then $10 and $20 per member per month. Both are betting on the same thing: that a team of eight gets meaningfully more value out of the product than a team of two, because more people collaborating in the same workspace is the actual product experience.
That bet holds up well for anything genuinely collaborative — project trackers, docs, chat. It falls apart for tools where one power user does the real work on behalf of a team that never logs in. A single analyst running all the queries in a BI tool, or one engineer maintaining an internal dashboard everyone else just glances at, makes every additional seat read as pure cost with no matching benefit, and buyers notice that math quickly. Per-seat pricing selects for products that are collaborative by nature, and it punishes products that are used by one person on everyone else's behalf.
Model | What it selects for | Where it breaks |
|---|---|---|
Per-seat (Linear, Notion) | Genuinely collaborative products where headcount using the tool tracks value delivered | One power user doing the work for a whole team; every added seat is pure overhead |
Usage-based (Vercel compute/bandwidth) | A clean, hard-to-game value metric that scales with what's consumed | No obvious metric, or a metric customers can shrink without losing real value |
Freemium (Notion's free tier) | Near-zero marginal cost per free user and a product worth using free on its own | Expensive-to-serve free users, or a free tier so limited it reads as a nag screen |
Outcome-based | A trusted, contestable-free number both sides agree represents value | Attribution disputes the moment the metric isn't airtight |
Flat / unlimited-seat (Basecamp) | Buyers who want total budget predictability regardless of team size | Revenue that doesn't grow as the account grows, subsidized by your lightest users |
Usage-based: bets that consumption tracks value
Vercel layers metered usage on top of a $20/month seat: edge requests, data transfer, and compute — billed hourly on its Fluid Active CPU model past an included allowance — with pricing explicitly described on Vercel's own pricing page as 'pay as you go, uncapped' beyond the included credit. This only works when the thing being metered genuinely tracks the value delivered. Bandwidth and compute do that reasonably well for infrastructure — a customer serving ten times the traffic is plausibly getting ten times the value.
The risk with any usage-based model is picking a metric customers can optimize around without giving up real value, which just makes them angry at your invoice instead of happy with your product. A deeper look at how Vercel's bill actually adds up covers this from the buyer's side, and it's worth reading before you copy this model, because the same mechanics that make usage-based pricing fair also make it the pricing structure buyers complain about most loudly on social media. There is a longer treatment of the operations side of this in . There is a longer treatment of the operations side of this in The XenGrowth resource library.
Freemium: bets on a small conversion rate at real scale
Notion's free tier isn't a crippled fourteen-day trial — it's a genuinely usable product for an individual organizing their own notes, with no time bomb attached. That distinction is the entire model. Freemium only works when the cost of serving a free user is close to zero and the free product is good enough that people stick around, invite others, and eventually hit a real limit — more members, more advanced permissions — that the free tier was never meant to cover.
A free tier built as an unconvincing trial with a countdown clock converts worse than a genuinely useful free product does, because people can tell the difference between 'this is free' and 'this is temporarily free to get you hooked,' and the second one reads as manipulative the moment it's noticed. Once a freemium motion is actually running, tracking which free users are worth pursuing for conversion is a measurement problem more than a product one — the kind of instrumentation is specifically built around.
Flat and one-time: bets on predictability over upside
Basecamp has run flat pricing with no per-user charge for well over a decade, and its own pricing page is blunt about it: 'no per-user fees, everyone's included.' Above its entry tier, a team can add as many people as it wants at zero incremental cost. That's a deliberate rejection of the per-seat model, made by a company that could clearly charge per seat if it wanted to.
The tradeoff is honest and worth stating plainly: Basecamp gives up all the revenue upside that comes from a growing team, in exchange for a genuinely predictable bill that buyers can budget against without worrying that hiring five more people means a bigger invoice next month. It's the right model when your buyer's biggest objection isn't the price, it's the fear that the price will keep changing on them. approaches this from the AI agents and marketing automation side. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
There's a second failure mode worth naming separately from the nag-screen problem: a free tier generous enough that almost nobody ever needs to upgrade. That's not success, even though the signup number looks great in a board deck. A free tier has to be genuinely useful and still leave a real, findable ceiling — more collaborators, a feature a growing team actually needs — or the whole model just subsidizes free users forever without ever collecting the conversion it was designed around.
Outcome-based: bets that a value metric everyone trusts exists
Outcome or value-based pricing ties what you charge to a measured result — revenue generated, cost avoided, leads produced — rather than to seats or usage at all. It's the tightest possible alignment between vendor and customer incentives, because the vendor genuinely doesn't get paid unless the customer wins by whatever number both sides agreed on in advance.
It's also the hardest model to actually run, because it depends entirely on a value metric that's clean, agreed, and hard to dispute. The moment attribution gets murky — was this lead really caused by your tool, or would it have converted anyway — outcome-based pricing stops being a pricing model and turns into a running argument about measurement. It fits sales-led motions with a genuinely trusted number far better than it fits a self-serve signup flow where nobody's had that conversation.
What the same four companies actually charge
Put the real numbers next to each other and the philosophical differences turn concrete. None of these four companies picked an arbitrary price — each price is shaped by the bet described above, and the shape is visible in the structure of the bill, not just the size of it. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
Company | Entry price | What scales the bill |
|---|---|---|
Linear | $10/user/month (Basic) | Number of people on the team, billed monthly per person |
Notion | $10/member/month (Plus), plus AI credits at $10/1,000 credits | Members for the base plan; AI usage separately, on top |
Vercel | $20/month seat (Pro), plus metered compute and bandwidth | Seats for the base plan; consumption uncapped past included credit |
Basecamp | $59/month (Studio), unlimited users included | Nothing — the bill is flat regardless of how many people join |
Notice that two of the four — Notion and Vercel — don't pick a single model at all. They layer a predictable seat charge underneath a variable usage charge, which is itself a legitimate answer to the tension between what buyers want (predictability) and what vendors want (revenue that tracks value). A hybrid isn't indecision; it's an admission that a single number rarely captures both halves of what a buyer needs and what a business needs to stay solvent.
The metric comes first, the model comes second
Every one of these models is really just a different way of billing against a value metric, once you've identified what that metric actually is. Seats, when people using the product are the metric. Consumption, when usage is the metric. A flat number, when no clean metric exists yet, or when your buyer would rather pay for certainty than for precision.
Picking a pricing model before you've identified your value metric is like picking a currency before you've decided what you're selling — it's not wrong exactly, it's just not the actual decision that matters.
It's tempting to copy whatever the market leader in your category does, and sometimes that's the right call — it usually means the buyer is already trained to expect that shape of bill. But Linear, Notion, Vercel and Basecamp made four genuinely different bets in four genuinely different situations, and none of them is obviously 'the' right model in the abstract. The right model is the one that matches what your product actually does for a customer, and how honestly you can measure that.
A short process for actually deciding
Write down the one number that best represents the value a customer gets — not a proxy you already track because it's easy, the actual value metric
Check whether that metric is something the customer would also call fair if they saw it broken out on an invoice; if not, look for a different one before you build billing around it
Decide how much your specific buyer values predictability over precision — a budget-constrained buyer wants a flat or seat-based number even if it's technically less fair than usage-based
Model your own cost to serve at both the lightest and heaviest end of usage, because a model that only works for the average customer will quietly lose money on your extremes
Expect to revisit this. Pricing models that fit a ten-person company routinely stop fitting at a thousand customers, and treating the first choice as permanent is its own mistake
Where this work meets go-to-market
A pricing model is only half the story — the other half is whether acquisition spend and channel economics actually line up with the model you picked, which is squarely for teams turning a pricing decision into an actual revenue motion.
Further reading from XenGrowth
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of pricing models for a technical product, compared, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of pricing models for a technical product, compared, see XenGrowth's growth engineering practice.
Five questions about your product's usage pattern, your buyer, and how you sell, then a starting point.
