Usage-Based, Seats, or Flat? Pricing Architecture Before You Build
Founders usually treat pricing as a launch-week decision: pick three tiers, name the middle one “Growth,” ship it. Then six months later they want to charge by usage, and discover the product never counted anything. Pricing is architecture. The billing model you might ever want determines what the software must measure from its very first day.
The three models, honestly
- Per-seat: easy to understand, easy to build, and quietly anti-growth — customers fight seat expansion, and your revenue caps at their headcount.
- Flat-rate tiers: fastest to launch and great for wedge products, but big customers get a bargain and small ones subsidize them.
- Usage-based: aligns price with value and grows revenue without sales calls — at the cost of real engineering: metering, aggregation, alerts, and bills customers can predict.
The architectural point
You don't have to launch with usage pricing. You do have to decide whether it's ever plausible, because retrofitting metering into a system that never recorded events is a rewrite wearing a small hat. The cheap insurance is an event stream: from day one, record the countable actions — documents processed, messages sent, gigabytes stored — even if nothing bills against them yet.
That single decision costs a few days early and buys you every pricing experiment you'll ever want to run. The companies that win on pricing aren't the ones that guessed right at launch; they're the ones whose architecture let them change their mind cheaply.