To price a SaaS product well, pick a value metric that grows with the value customers receive (seats, active users, API calls, storage, transactions), instrument your product to measure that metric accurately, and confirm each plan earns healthy gross margin after your real cost to serve. Pricing is not just a marketing exercise: the model you choose is only as good as the engineering that meters usage, enforces entitlements, and lets you change plans without redeploying. Get the instrumentation right first, then set numbers you can defend and revisit.
Why is SaaS pricing an engineering problem?
Business teams usually own the number on the pricing page, but engineering owns whether that number is measurable, enforceable, and changeable. If your architecture cannot count the thing you charge for, you cannot bill for it fairly. If plan limits are hard-coded, every pricing experiment becomes a release. And if you never attribute cloud cost to customers, you are guessing at margin.
Three engineering realities quietly constrain pricing:
- What you can measure. You can only charge for events you reliably capture, deduplicate, and store.
- What you can enforce. Limits and features must be gated in code without shipping a build every time a plan changes.
- What it costs to serve. Infrastructure, third-party APIs, and support all consume margin, and they vary widely by customer.
Treating these as afterthoughts is how teams end up with a beautiful pricing page and a billing system that cannot support it.
What are the main SaaS pricing models?
Most SaaS pricing is a variation or combination of a handful of models. Each carries different engineering demands.
- Flat-rate: one price for the whole product. Simplest to build and communicate, but leaves money on the table with large customers and scares off small ones.
- Per-seat: price scales with the number of users. Easy to meter and forecast, but weak when value is not tied to headcount and easy to game by sharing logins.
- Usage-based (metered): customers pay for consumption such as API calls, compute, or messages. Aligns price with value but demands accurate, auditable metering and clear invoices.
- Tiered: good/better/best packages with different limits and features. The most common B2B pattern; it needs a solid entitlement system to gate each tier.
- Hybrid: a base subscription plus usage overages. Predictable revenue with upside, but the most complex to implement and explain.
- Freemium: a free tier that converts to paid. Powerful for adoption, but only viable if your free cost-to-serve is genuinely low.
How do you know your cost to serve?
Gross margin is where engineering decisions meet the P&L. Before setting any price, calculate the fully loaded cost of serving one customer, sometimes called cost of goods sold (COGS) for software. It typically includes cloud infrastructure, third-party and AI API fees, data egress and storage, payment processing, and a share of support.
The hard part is attribution: a shared multi-tenant system does not hand you per-customer cost by default. Practical steps:
- Tag cloud resources by tenant, environment, and feature so spend can be allocated. The AWS Well-Architected cost optimization pillar is a solid reference for expenditure awareness.
- Instrument the expensive operations, especially anything that calls a metered external API (LLM tokens, SMS, mapping, KYC), since these can turn a profitable account unprofitable overnight.
- Model your worst-case power user, not the average, because outliers concentrate cost and define where you need caps or overage pricing.
If a plan cannot clear a comfortable gross margin at realistic usage, no amount of marketing will fix it.
Engineering foundations for pricing that can evolve
Your first price will be wrong. That is normal. The goal is to build so that changing it is cheap.
Meter the right events accurately
Emit a durable, idempotent usage event for anything you might bill on, even if you do not charge for it yet. Store raw events, aggregate for invoicing, and keep them auditable so customers can reconcile their bill. Billing platforms like Stripe Billing document usage-based and metered patterns worth studying before you build your own.
Separate entitlements from application code
An entitlement layer answers one question: is this account allowed to do this, and up to what limit? Keep that logic out of scattered if checks and behind a central service or feature-flag system so a plan change is a data change, not a code change.
Make plans data, not deployments
Represent plans, limits, and prices as configuration in a database, not constants in the codebase. This lets you launch a new tier, grandfather existing customers, or run a pricing experiment without a release, which is exactly what you will want to do repeatedly.
How do you choose a value metric?
The value metric is the single most important pricing decision. A good one is easy for the customer to understand, scales with the value they get, and is predictable enough that they are not afraid of a surprise bill. Ask three questions: Does it grow as the customer succeeds? Can the customer roughly predict their own usage? Can you meter it cleanly and defend the number on the invoice? When seats, usage, and outcomes point in different directions, favor the metric that most closely tracks realized customer value while staying simple to bill.
Common engineering mistakes when pricing SaaS
- Hard-coding limits so every plan tweak requires a deploy.
- Billing on data you never captured reliably, forcing awkward estimates.
- Ignoring cost-to-serve until a whale customer erodes your margin.
- No idempotency in usage events, producing double-counted or lost charges.
- Coupling pricing to a single vendor so a migration means rebuilding billing.
- Unbounded free tiers whose infrastructure cost quietly outruns conversion revenue.
A practical process to set your first price
- Identify the value metric and confirm you can meter it end to end.
- Calculate fully loaded cost to serve for average and heavy customers.
- Design two or three tiers with clear differentiation and generous headroom.
- Build entitlements and plans as configuration, not code.
- Set prices anchored to customer value and competitive context, then verify margin.
- Instrument everything, launch, and treat the price as a living variable you revisit quarterly.
Frequently asked questions
Should a startup start with usage-based or per-seat pricing?
Per-seat is simpler to build, forecast, and sell, so many early B2B products start there. Choose usage-based when value clearly tracks consumption rather than headcount, but only if you can meter accurately and give customers predictable bills. A hybrid base-plus-usage model is common once the product matures.
How much does pricing model choice affect engineering cost?
Significantly. Flat-rate and per-seat are cheap to implement; metered and hybrid models require durable event pipelines, aggregation, idempotency, and reconciliation. Budget for a real billing and entitlement layer if you expect usage-based pricing, and design it before launch rather than retrofitting later.
How often should you change SaaS pricing?
Review pricing regularly, at least once or twice a year, and adjust as you learn about value, cost, and competition. Frequent changes are healthy only if your architecture makes them low-risk. Grandfather existing customers and communicate changes clearly to preserve trust.
What is a healthy gross margin for SaaS?
Mature software businesses generally aim for high gross margins, often well above two-thirds of revenue, because scaling should not scale cost proportionally. If a plan cannot reach a comfortable margin at realistic usage, revisit the metric, the limits, or the cost structure before launching it.
How Direlli can help
Direlli builds the engineering foundations that make pricing defensible: accurate metering, entitlement systems, usage-based billing integrations, and cost-attributed multi-tenant architecture. Rated 5.0 on Clutch and serving clients across the US, Europe, and MENA, our team can design and implement the SaaS development infrastructure behind your pricing model. Talk to Direlli to pressure-test your pricing engineering, or /contact us to start building.
