Pricing is a business decision with massive technical consequences. We have watched founding teams spend weeks debating pricing strategy without once consulting their engineering team, only to discover that implementing their chosen model requires months of development work. The pricing model you choose affects your database schema, your authentication system, your billing infrastructure, your API design, and your monitoring stack.
We have built billing systems for SaaS products across every pricing model. Here is what each one actually requires from an engineering perspective, so you can make the pricing decision with full information. We also recommend reading our guide on subscription billing architecture for the implementation details.
Flat Rate Pricing
The model: One price, one plan, everyone gets everything. Basecamp is the classic example.
Engineering complexity: Low. This is the simplest model to implement. Your billing system needs to handle exactly one subscription tier. There is no metering, no usage tracking beyond basic analytics, and no plan comparison logic in the UI. Stripe or any payment processor handles this with a single subscription product.
What you build:
- A subscription table with user_id, status, and renewal_date
- Webhook handlers for payment success, failure, and cancellation
- A simple gate: is the user subscribed or not?
- Grace period logic for failed payments (we recommend 7 to 14 days)
The trade off: You leave money on the table from high usage customers and price out low usage prospects. But you ship faster because the billing system is trivial. For early stage products, this trade off is almost always worth it.
Per Seat Pricing
The model: Price scales with the number of users. Slack, Notion, and most B2B SaaS tools use this.
Engineering complexity: Medium. You need an organization system with member management, invitation flows, role based access control, and seat counting that integrates with your billing system.
What you build:
- Organizations/teams/workspaces as a first class entity in your data model
- Invitation and onboarding flows (email invites, link sharing, domain based auto join)
- Role based permissions (admin, member, viewer) with corresponding UI gates
- Seat count synchronization with Stripe: when a member is added, the subscription quantity increments; when removed, it decrements
- Proration logic for mid cycle seat changes
- An admin dashboard showing current seat usage and billing impact
The hidden complexity: Seat based pricing creates UX friction. Users hesitate to invite teammates because each invite costs money. This directly hurts adoption and virality. We have seen products solve this by offering free viewer seats (Figma's approach) or by pricing per "active" seat rather than per provisioned seat. Both add engineering complexity but significantly improve adoption metrics.
Proration is harder than it looks. When someone adds 3 seats on day 15 of a monthly billing cycle, your system needs to charge exactly half a month for those seats, then the full amount on the next cycle. Stripe handles the math, but your application needs to communicate the charges clearly to users and handle edge cases like adding and removing the same seat within one billing period.
Usage Based Pricing
The model: Customers pay for what they use. AWS, Twilio, and OpenAI use this model.
Engineering complexity: High. This is the most technically demanding pricing model because it requires real time metering infrastructure.
What you build:
- A metering system that tracks every billable event (API calls, messages sent, storage used, compute minutes, whatever your unit is)
- An event pipeline that is durable and exactly once. If you lose metering events, you lose revenue. If you double count, customers dispute charges. This is a distributed systems problem.
- A usage aggregation service that rolls up raw events into billing periods
- Real time usage dashboards so customers can see their spend (this is not optional; customers will leave if they cannot predict their bill)
- Alerting and spending caps so customers can set limits and get notified before they hit them
- A billing calculation engine that applies tiered or volume pricing to aggregated usage
The infrastructure: We typically implement metering with an append only event stream (Kafka, AWS Kinesis, or a purpose built table in Supabase) feeding into a time series aggregation layer. The metering pipeline must be more reliable than the product itself, because a metering outage means revenue loss.
The trade off: Usage based pricing aligns cost with value perfectly, which makes it the fairest model. But it creates revenue unpredictability (for you) and bill anxiety (for customers). Companies like Vercel and PlanetScale have moved away from pure usage pricing partly because customers churned over unexpectedly high bills.
Tiered Pricing
The model: Multiple plans with different feature sets and limits. Most SaaS products land here: a Free tier, a Pro tier at $29 per month, and an Enterprise tier with custom pricing.
Engineering complexity: Medium to High. You need a feature flagging system that gates functionality by plan, plus all the upgrade and downgrade logic.
What you build:
- A plan configuration system (ideally database driven, not hardcoded) that defines which features, limits, and capabilities each tier includes
- Feature gates throughout your application: can this user access this feature? Has this workspace exceeded its storage limit?
- Upgrade and downgrade flows with proration
- A plan comparison page (this is a high impact marketing page, not just a technical requirement)
- Limit enforcement: what happens when a user on the free plan exceeds 1,000 API calls? Do you block, throttle, or prompt an upgrade?
- Trial management: trial start, trial end, conversion nudges, trial extension for promising leads
The architecture decision that matters most: Make your plan definitions data driven from day one. We have seen products hardcode plan logic with if/else statements scattered across the codebase. Adding a new plan or changing a limit becomes a multi day engineering project. Instead, store plan definitions in a configuration table and have your application check against it. Changing a plan limit becomes a database update, not a code deployment.
For the metrics you should be tracking alongside your pricing model, our SaaS metrics guide covers the numbers that actually predict growth.
Freemium
The model: A free tier that serves as the top of your funnel, with paid tiers for power users or teams.
Engineering complexity: High. Freemium combines tiered pricing complexity with massive scale requirements. Your free tier will generate 10 to 50x more users than your paid tier, and all of them need to be served reliably.
What you build: Everything from tiered pricing, plus:
- Infrastructure that handles a much larger user base at near zero marginal cost per free user
- Conversion optimization: in app upgrade prompts, usage limit notifications, feature teasers
- Abuse prevention: free tier accounts being used for spam, scraping, or resource mining
- Data retention policies for free accounts (you cannot store everything forever for users who are not paying)
The trade off: Freemium is a growth strategy, not a pricing strategy. The engineering cost of supporting a large free tier is real: more database rows, more API calls, more support tickets, more infrastructure cost. We have seen startups spend 60% or more of their infrastructure budget serving free users. The math only works if your paid conversion rate is high enough to cover it. For most B2B SaaS, a 2% to 5% conversion rate from free to paid is typical. If your paid ARPU is not high enough to support 20 to 50 free users per paying customer, freemium will drain your runway. This directly connects to the decision between self serve and sales led approaches.
Our Recommendation for New Products
Start with flat rate or simple tiered (two to three plans). Ship the product, get customers, and learn what they actually value. You can always add complexity later, but you cannot easily remove it.
The technical foundation matters though. Even if you launch with flat rate pricing, build your billing system with the assumption that you will add tiers or usage components later. Use a payment processor that supports all models (Stripe is our default recommendation). Store subscription data in a way that can accommodate plan changes. Build feature access checks even if they all return true today.
We cover the full product building process in our guide to building a SaaS product. Getting the billing architecture right from the start saves months of refactoring later.
We build SaaS billing systems as part of our full stack development work, from simple Stripe integrations to complex usage based metering pipelines. If you are making pricing decisions and want to understand the engineering implications before you commit, let us walk through it with you.