SaaS Pricing Page Design: Choose References That Fit

Choose SaaS pricing page design references by matching three things: what the customer pays for, what changes between plans, and how they buy. Then name the specific behavior you will borrow. A useful reference brief explains those choices, rejects mismatched patterns, and checks billing clarity before anyone copies the visual treatment.

You need your actual offer, a few reference URLs, and somewhere to write notes. You do not need to decide your prices by studying someone else's cards. If packaging is still unsettled, mark it as an open product decision rather than letting a screenshot decide it for you.

The workflow is short:

1. Write the buying decision and billing unit.
2. Select references for specific questions, not whole-page imitation.
3. Record what to borrow, adapt and reject.
4. Test the brief against realistic buying scenarios before building.

1. Write the decision your pricing page must support

Start with: “A visitor needs to choose which option, estimate which cost, and take which next step.” This is more useful than “we need a modern pricing page.”

For a seat-based product, the estimate may depend on who counts as a paid user. For a usage-based product, it may depend on activity the customer has not measured yet. For a quote-led service, a public total might not be possible; the page can still explain what affects the quote and what happens after an enquiry.

Write down these inputs before opening your references:

• Billing unit: user, workspace, project, usage allowance, or another defined unit.
• Plan difference: the capability or limit that makes someone choose a different package.
• Commitment: recurring interval, minimum commitment and any annual-payment conditions.
• Buying path: signup, trial, checkout, quote or a combination.
• Unresolved detail: anything your own team has not decided, such as overage behavior.

These are requirements, not necessarily five sections on the page. Some fit beside a price; others need a comparison row or a short explanation. Your first deliverable is a plain-language description of the offer. If you cannot write it, collecting more layouts will not resolve the missing decision.

2. Read three pricing page design examples for different jobs

The examples below were checked on October 10, 2026. They illustrate different decisions, not a ranking or a conversion study. Packaging can change; follow the official links before using an example in a project. Our observations describe the published content, not a full usability test of each site's controls or checkout.

Linear: distinguish paid seats from plan capabilities

Linear's pricing page combines per-user pricing on Basic and Business with differences in capabilities and limits. Business has both a self-service entry point and a sales contact option; Enterprise directs visitors to sales.

Borrow: the separation between the unit being charged and the reasons to choose a plan. This is a useful question to bring to your own draft: can someone identify both without confusing a feature upgrade with adding another user?

Adapt: define your own billable roles. If guests or viewers are treated differently, say so using your actual rules. Do not assume another product's definition of a user applies to yours.

Reject when mismatched: a per-seat price treatment for a product sold by workspace. You can still study typography or the placement of supporting details, but the price label is not transferable. A sales button is also not automatically right for your highest tier.

Plausible: separate usage from feature choice

Plausible's pricing section combines a monthly-pageview selector with plans that differ in capabilities and allowances. Starter, Growth and Business offer trial actions, while Enterprise provides a contact path.

Borrow: treating expected usage and required capabilities as distinct inputs. If a customer needs both to estimate the right package, do not hide one inside an unexplained plan name.

Adapt: use your actual measured unit and explain how someone can estimate it. A selector labelled with a technical unit still needs context if the buyer does not know their usage. Include the selected allowance near the resulting offer so the price is not detached from its assumptions.

Reject when mismatched: a usage selector for a product whose price does not vary with usage. Extra interaction would ask the visitor to make a decision your offer does not require. This example is not evidence that every SaaS needs a calculator.

Basecamp: make the boundaries of a fixed package visible

Basecamp's pricing page presents fixed packages without per-user fees, differentiated partly by project and storage allowances. That does not mean every package has unlimited users: its Free and Freelancer options have user caps.

Borrow: explaining what the package covers and where its limits sit. A fixed fee still needs a clear scope. “Not charged per user” and “unlimited users” are different claims.

Adapt: make the limits relevant to your own buyer's work. For a client portal, active client workspaces may be more useful than a long list of small interface features.

Reject when mismatched: another company's unlimited promise. Borrow the way an allowance is explained, not the allowance itself. If your own service has a cap, show it; do not conceal it to make the card look simpler.

3. Turn the examples into a completed reference-selection brief

Here is a hypothetical client-portal product. It is not a TastefulKit customer or a pricing recommendation. Assume its owner has already decided to charge one fixed monthly fee per agency, offer two plans with different active-client limits, include internal teammates, and start customers through a trial.

The designer's job is to explain that offer, not redesign it around a favorite screenshot.

Buying decision: “An agency chooses a plan by the number of active clients it supports, confirms that teammates are included, and starts a trial.”

Primary uncertainty: “Does each new teammate add another charge?” This is a hypothesis for reader testing, not a finding from customer research.

This produces a buildable first outline:

1. A short explanation that the fee covers an agency and includes internal teammates.
2. Two plan cards, each with its real active-client limit beside the price.
3. A compact comparison of the few differences that could change the choice.
4. An explanation of what happens when an agency reaches its limit.
5. Trial terms and a trial action that matches the actual signup flow.

The limit behavior is intentionally unfinished until the product owner supplies it. Do not invent automatic upgrades, overage fees or uninterrupted access. Label the missing decision in the working brief; resolve it before publishing customer-facing copy.

If the same product instead offered only custom contracts, the reference choice would change. Keep the scope questions and useful comparison language, but do not manufacture two public price cards. Explain the factors used for a quote, what information the enquiry needs, and the next step. The layout follows the real buying path.

4. Check the brief against a buyer's actual questions

Give the outline to someone who has not read your notes. Ask them to work through specific scenarios without explaining the answers first. This is a comprehension check, not a conversion experiment.

For the hypothetical portal: Which plan would you choose for your current clients? What changes if you invite another teammate? What happens when you add one more client beyond the plan limit? What will the trial ask you to do?

Record where the person hesitates or makes an assumption. A comment such as “the cards look balanced” is less useful than “I thought this amount was per teammate.” Fix the latter in the offer wording before changing spacing.

For annual billing, check that the displayed monthly equivalent cannot be mistaken for a monthly payment option. Keep the commitment and charge timing next to the relevant amount. If a toggle changes the offer, review the labels and terms in both states rather than checking only the cheaper-looking default.

For usage pricing, test a low-usage and a high-usage scenario with the product's real rules. State what an estimate includes and what it excludes. An attractive estimate with unspecified overages is not a complete answer.

On mobile, verify the relationship between a feature and its plan. A comparison row that made sense across several desktop columns may become ambiguous when cards stack. Keep labels attached to values, give controls clear names, and check the page with realistic long feature names. Our mobile landing-page review workflow gives you a broader small-screen checklist.

5. Save a brief someone else can build from

Use the following fields for each reference you keep. They work in a document, a design file or an AI coding-agent brief:

• Source and date: the exact public page and when you checked it.
• Question it answers: the one pricing decision this reference helps explain.
• Observed behavior: what you saw, separated from what you assume.
• Borrow: one named structural or visual principle.
• Adapt: the real content and rules needed for your product.
• Reject: a tempting element that would misstate your offer.
• Unknown: an interaction, term or billing rule still requiring verification.
• Acceptance check: a buyer question the finished page must answer.

Avoid handing over “make it like Linear.” A better instruction is: “Keep the plan name, billing unit and commitment together. Use our per-agency wording. Do not introduce seat pricing or a sales-only tier. Leave unresolved limit behavior flagged until we provide the rule.”

For additional visual directions, browse TastefulKit's public reference library or use the search guide to narrow a description. You can inspect public screenshots and available DESIGN.md guides without an account; saving a shortlist requires a free account. References help explain a design decision, but they do not provide a licence to copy a site's assets or proof that its pricing page converts well.

Start with one reference and fill in its reject field. If nothing seems non-transferable, revisit your own billing unit and buying path before adding more screenshots.