Metrics & Pricing

How to design a SaaS pricing page: anatomy, patterns and mistakes

The parts of a SaaS pricing page that help buyers decide, which layout fits your pricing model, a per-seat and annual price worked through, and a checklist.

Isometric 3D illustration of two acid lime green takeaway cups with rounded lids, a small one with a ribbed sleeve beside a tall one, on a white disc against a pale background.

You have a product people sign up for, a price you thought hard about, and a pricing page where visitors look, scroll and leave. Your pricing page has one job: help the right buyer pick a plan and start, without a sales call. This guide takes the page apart, shows which layout fits which pricing model, and works a per-seat and annual price through with numbers.

The page is not where you decide your pricing model. If you are still choosing between per-seat, usage-based, tiered or freemium, start with SaaS pricing models compared. For the basics of the subscription business behind the page, see What is SaaS?.

A pricing page in plain terms

Think of it like the menu board above a coffee counter. You read it in a few seconds, standing in line. Sizes are named, prices are big, and the size most people order is easy to spot. Nobody asks to talk to a manager to learn what a medium costs.

A SaaS pricing page is that menu board for software. It lists your plans, says what each one costs and for whom, and ends in a button that starts a trial or a purchase. Visitors often open it right after the homepage. A buyer who cannot answer “which plan, and what will it cost?” in under a minute usually leaves.

The anatomy of a pricing page that helps buyers decide

Read your own page against these eight parts, top to bottom.

  1. Plan names that say who the plan is for. “Solo”, “Team” and “Business” tell a buyer where they fit. “Silver” and “Gold” tell them nothing.
  2. The price with its unit and period. “$20 per user per month, billed yearly” is complete. “$20” alone hides the unit, and the buyer has to guess.
  3. One recommended plan. Mark the plan most of your customers choose, with a label and a stronger border. One highlight, not two.
  4. The differences that justify each upgrade. Under each plan, list what it adds over the one before. “Everything in Team, plus SSO and audit logs” reads faster than 20 check marks.
  5. A specific call to action per plan. “Start a 14-day Team trial” says what happens next. “Get started” on every card does not.
  6. An honest billing switch. If you offer an annual discount, show both prices and the real saving. Say which one is on screen.
  7. A full comparison table below the cards. Buyers who need detail scroll to it. Use a real HTML table so it works with screen readers and on a phone.
  8. Answers to the questions that stop a purchase. Can the buyer cancel anytime? Does the trial need a card? Is there a refund? Are taxes included? Put the answers on the page, not in a help center.

Linear’s pricing page shows several of these parts. As of November 8, 2026, it lists Free at $0, Basic at “$10 per user/month” and Business at “$16 per user/month”, each paid plan marked “Billed yearly”. Enterprise shows “Custom” with a “Contact sales” button, and a feature comparison table follows the plans.

Which layout fits your pricing model

The layout follows the pricing model, not the other way around. This table pairs each common model with the page structure that fits it.

Your pricing model Layout that fits What the page must show
Tiered, flat price Three tiers, middle one highlighted What each tier adds over the one before
Per-seat Price per user plus a seat-count table The total at 5, 10 and 25 seats
Usage-based Pay as you go with volume tiers The unit, the included amount, the overage price
Freemium plus sales Free, paid and a “talk to sales” lane Free plan limits, and what triggers a sales call
One price Single plan, everything included What is included, and the usage limits
Developer API Rate limits, quotas and overage Requests per minute, monthly quota, cost per extra call
Prepaid credits Credit packs What one credit buys, and whether credits expire

A page that mixes two of these, such as seats and usage, needs both sets of numbers. Show the seat price first and the usage limits right under it. For AI features sold as credits or per action, see AI pricing in SaaS.

A per-seat and annual price, worked through

Example: a hypothetical scheduling tool sells a Team plan per seat. It charges $24 per user per month billed monthly, or $20 per user per month billed yearly.

First, the annual saving per seat:

  • Billed monthly for a year: $24 x 12 = $288.
  • Billed yearly: $20 x 12 = $240.
  • Saving: $288 - $240 = $48 a year, and $48 / $288 = 16.7%.

So the honest label is “save 16%”, rounded down. “Save 20%” would be wrong, because $4 / $24 is 16.7%, not 20%. The 20% figure only appears if you divide the $4 difference by the lower price.

Next, the totals a buyer needs to see:

Seats Billed monthly, per month Billed yearly, per year
5 5 x $24 = $120 5 x $240 = $1,200
10 10 x $24 = $240 10 x $240 = $2,400
25 25 x $24 = $600 25 x $240 = $6,000

A team lead with 10 people now sees $2,400 a year without opening a calculator. That number goes to whoever approves the spend, so put it on the page.

A real page shows the same pattern. Basecamp’s pricing page, as of November 8, 2026, shows Pro Unlimited at “$199 /mo, billed annually” and “$329/mo if billed monthly”. That is $199 x 12 = $2,388 a year against $329 x 12 = $3,948. The difference is $1,560, or $1,560 / $3,948 = 39.5% off the monthly-billing price.

Starting from a template

You can build every part above by hand in a day or two. If you would rather start from working code, SaaSCron sells its own Pricing Page Kit for $49, one time. It has 12 layouts in plain HTML and CSS that match the models in the table above. It also has a teardown guide on when to use each one, and an agent skill for Claude Code and Cursor. The skill picks a layout from your answers and leaves a visible TODO where your data is missing.

Disclosure: SaaSCron makes and sells the Pricing Page Kit. Everything else in this guide applies whether you use it or not.

Checklist

Before you publish your pricing page, tick each line:

  • Each plan name says who the plan is for.
  • Every price shows its unit (per user, per month, per 1,000 calls) and its billing period.
  • Exactly one plan is marked as recommended.
  • Each plan lists what it adds over the plan before it.
  • Every button says what happens next, such as “Start a 14-day trial”.
  • The annual saving is computed against the monthly-billing price and rounded down.
  • Per-seat plans show a total for a typical team size.
  • Usage-based plans show the included amount and the overage price.
  • The comparison table is a real table, readable on a phone.
  • Cancellation, trial, refund and tax questions are answered on the page.
  • The page loads fast and works without JavaScript.

On that last point, pricing is one of the pages your buyers open most, so it falls under the same speed limits as your homepage. See what good SaaS sites put above the fold for the Core Web Vitals thresholds.

Common mistakes

  1. Listing every feature on every card. Twenty check marks per plan hide the three that matter. Why it happens: the product team wants credit for everything it built. Instead: show the upgrade differences on the cards and move the full list to the comparison table.
  2. Showing the annual price without saying so. A buyer sees $20, starts checkout and finds a $240 charge. Why it happens: the lower number looks better on the card. Instead: write “billed yearly” next to the price and show the monthly-billing price one click away.
  3. Overstating the saving. “Save 20%” on a $24 to $20 discount is wrong; the saving is 16.7%. Why it happens: the difference is divided by the lower price. Instead: divide the saving by the monthly-billing total, as in the example.
  4. Hiding every price behind “contact sales”. Small teams leave instead of booking a call. Why it happens: sales wants a conversation with every lead. Instead: publish self-serve prices and keep “contact sales” for the plan that needs custom terms.
  5. Making the page heavy. Pricing calculators and sliders that load large scripts slow the page on a phone. Why it happens: interactive widgets look modern in a demo. Instead: use tables and a CSS-only switch, and add a script only when the buyer truly needs to compute something.

Sources

  • Linear, Pricing, checked November 8, 2026.
  • Basecamp, Pricing, checked November 8, 2026.

In three sentences

A SaaS pricing page helps the right buyer pick a plan and start without a sales call. It works when each plan names its buyer, every price shows its unit and billing period, and one plan is clearly recommended. Pick the layout that matches your pricing model, show real totals such as $2,400 a year for 10 seats, and compute any annual saving against the monthly-billing price.

Frequently asked questions

What should a SaaS pricing page include?

Plan names that say who each plan is for, a price with its unit and billing period, one recommended plan, the few differences that justify each upgrade, a specific call to action per plan, a full comparison table below the cards, and short answers to the questions that stop a purchase: cancellation, trials, refunds and taxes.

How many plans should a pricing page show?

Most SaaS pricing pages show three or four, often with a free or enterprise option at the edges. Fewer plans make the choice easier. A single plan works when your buyers are alike and one price fits them all.

Should a pricing page show monthly or annual prices by default?

Show the price the buyer will most likely pay, and label it. If the default is the annual price shown per month, say 'billed yearly' next to it and show the monthly-billing price one click away. A buyer who discovers the real charge at checkout leaves.

Should a SaaS company hide prices behind contact sales?

Only for the plan that really needs a quote, such as enterprise deals with custom terms. Self-serve plans should show their price. A page with no prices at all forces every buyer into a sales call, and many will not book one.

Does a pricing page need JavaScript?

No. Plan cards, comparison tables and even a monthly and annual switch can be built with HTML and CSS only. That keeps the page fast and readable on any device, which matters because pricing is one of the pages buyers open most.