Pricing Model

Common pricing models: flat-rate (one price, one set of features, simple but leaves money on the table with your biggest users and prices out your smallest ones), tiered (a few fixed packages, like Basic, Pro, and Enterprise, bundling features and usage limits together), per-seat (price scales with the number of users, common in collaboration tools like Slack, simple to forecast but can discourage adding teammates), usage-based (price scales with consumption, like AWS charging per API call, aligns cost with value but makes revenue harder to predict), and freemium (a free tier funds acquisition, a paid tier funds the business, works when the free tier is genuinely useful but not complete enough for serious use). The model you choose should match how your product delivers value, not what's easiest to build in Stripe. If value scales with usage, more API calls, more data processed, usage-based pricing captures that fairly, seat-based pricing doesn't. If value scales with team size, per-seat makes sense. Getting this wrong creates friction: tools that charge per seat regardless of usage push customers to under-provision seats and share logins, while usage-based tools with unpredictable bills create surprise-invoice anxiety that drives churn. Most early-stage teams start simpler than they think they need to: two or three tiers, clear feature gates, one annual discount. Add usage-based add-ons or custom enterprise pricing later, once you know which customers get more value and would pay more for it. Changing pricing model after launch is painful, existing customers resist being moved to a new structure, so the earlier you get the shape right, the less migration pain later.

Notion charges per seat for teams but offers a generous free tier for individuals, betting that value scales with how many teammates share a workspace. Twilio charges per SMS and API call instead, because its value scales with volume of messages sent, not number of logins.