What to include on an early SaaS pricing page

What to include on an early SaaS pricing page is a compact set of sections that let a buyer pick a plan without a sales call. Early SaaS pricing page work is packaging: clear tiers, honest limits, billing choices, and answers to the questions that already show up in chat.

Figma's pricing page guidance pushes a small number of plans, transparent prices, and a compact FAQ aimed at buying anxiety rather than filler (Figma: pricing page practices, checked 1 Nov 2026). Keep the layout plain and complete.

What belongs on an early SaaS pricing page first

An early SaaS pricing page should answer four questions above the fold: what it costs, who each plan is for, what limits apply, and how to start. If a visitor cannot answer those in a few seconds, rewrite before you add design polish.

It is not a novel. It is not a feature dump of every checkbox in the product. It is not a place to hide fees.

Illustrative pattern (composite only): three named plans, monthly and annual amounts next to each price, one recommended badge, a comparison of limits, a trial note, and six FAQ answers pulled from real sales questions.

Y Combinator's (YC) essential startup advice keeps pushing focus over empty process (Y Combinator Library, checked 1 Nov 2026). Use that filter: every block on the page should remove a buying question, not decorate the brand.

Put the plan cards where the eye lands

Show three or four plans. Figma notes that a large pile of plans increases tradeoff staring and slows buying (Figma, checked 1 Nov 2026). Early teams usually need fewer, not more.

Name plans for the buyer job or stage, not for internal code names. On the live Nautis pricing page the paid plan names are Launch, Voyage, and Fleet; check that page for current prices and trial terms instead of copying them here. Keep order low commitment to high commitment.

List a handful of features per plan that change the buying choice. Use "Everything in [lower plan], plus…" so readers are not re-reading the same bullets.

State whole numbers when you can. Put taxes and payment-provider fees in FAQ if they vary by region rather than surprising buyers at checkout.

Make billing period and trial rules obvious

Offer monthly and annual prices when both are real options. Show the annual saving next to the annual amount. Default presentation can favor annual if your retention supports it; still show monthly clearly so cash-sensitive buyers are not trapped.

Write what happens when a trial ends: auto-convert, pause, or require a card. Hidden trial endings create chargebacks and distrust.

If a plan is sales-led, say "Contact us" and what response time to expect. Do not put a fake self-serve button on an enterprise tier you cannot activate alone.

Link the page from navigation as Pricing. Buyers look for that word.

Show currency clearly. If you list USD only, say so. If prices localize later, avoid publishing a number you cannot charge today.

For seat-based plans, show whether the price is per editor, per active user, or per workspace member. Those words are not interchangeable at checkout.

Align the headline price with the checkout price. If the card shows one number and checkout adds mandatory packs, transparency failed.

Say whether renewals are automatic and how to cancel, at least in the FAQ. If you sell credits, add a labeled example of what a pack covers, not a vague promise.

When a plan includes support, define hours and channels. "Priority support" without a definition is decoration. Note that tax may apply by region so international buyers are not surprised.

For a live layout example, see Nautis pricing. Read that page for current plan prices and trial terms; this article does not restate dollar amounts.

Add a comparison that highlights limits, not ego

Below the cards, a simple comparison table helps readers who study details. Rows should be limits and capabilities that change price, not every micro-feature.

Keep tooltips short when a limit needs a definition. Long essays belong in docs, not in hover text.

Remove rows that are identical across all plans. Identical rows waste attention and make plans look fake.

Call out hard gates that force an upgrade: SSO, audit logs, dedicated support, or higher usage caps. Soft marketing adjectives do not belong in the grid.

If you sell seats, show seat minimums and overage rules in the same table. Buyers should not discover overages in an invoice.

Answer buying questions in a compact FAQ

Put five to eight questions under the plans. Figma recommends FAQs that handle buying anxiety and come from sales and support, not from keyword brainstorms (Figma, checked 1 Nov 2026).

Strong starters: Can I cancel anytime? What happens when the trial ends? Can I change plans later? Which payment methods work? Are there fees beyond the listed price? How does support differ by plan?

Answer in one to three sentences. Link to a policy page when legal detail is required, but keep the summary on the pricing page.

Skip FAQ entries that only restate marketing slogans. If sales never hears the question, cut it.

Prove the offer without turning the page into a brochure

Add a thin proof strip: logos you have permission to show, a short quote, or a counted outcome you can defend. One proof block beats a wall of testimonials.

Do not invent conversion rates or "most popular" claims without data. If you badge a plan as recommended, base it on who you want to buy or on observed choice share, and be ready to explain which.

Mobile layout should stack cards, keep CTAs visible, and avoid horizontal scroll for the comparison table. Many buyers open pricing on a phone between meetings.

Connect the page to your wider go-to-market work. Pricing clarity supports a 30-60-90 go-to-market plan more than another landing variant does.

Keep the page honest as you change prices

Date major price changes in a changelog or help note. Grandfather rules should be written where customers can find them.

When you add a tier, remove or merge one if the page grows past four. More tiers are not progress if buyers stall.

Review the FAQ against the last month of sales calls and support tickets. Replace stale answers.

After a price change, update screenshots in ads and sales decks the same day. Stale prices in collateral create disputes even when the live pricing URL is correct.

Keep a private changelog of plan names, prices, and limit edits with dates. Support needs that history when a customer quotes an old page.

Founders who already skim a daily founder briefing can park pricing-page fixes beside other product tasks so copy debt does not linger after a price change.

Common misses to refuse: "custom pricing" on every tier, feature lists that bury hard limits, annual prices shown without the monthly equivalent, and CTAs that all say "Learn more." Each miss sends buyers back to email.

If you discount heavily for annual, say the percentage next to the annual price. Silent discounts feel like tricks when someone toggles the period.

Test the page with one target buyer reading aloud. Wherever they hesitate, add a limit line or FAQ, not a new gradient.

Write the recommended plan for the buyer you want more of, not for the loudest internal stakeholder. If most happy customers sit on the middle tier, badge that tier and make its limits easy to scan.

When a feature is still unstable, keep it off the comparison grid or mark it as beta in one word. Pricing pages that promise unfinished work create refund conversations.

If you sell through partners, add a one-line partner path under enterprise rather than a fifth confusing card. Partners need a clear door, not another self-serve maze.

Photograph empty states only if they show real product UI you ship today. Mockups that do not match onboarding break trust on day one.

If legal requires regional plan differences, publish the region switcher near the prices rather than in a footnote buyers miss.

What to include on an early SaaS pricing page is enough structure for a confident choice: few plans, clear limits, visible billing rules, and FAQ answers you already give live. Write it so a stranger can buy without guessing.

Publish the pricing URL in the same release note as the product change that justifies a new limit. Quiet limit changes without a page update create angry upgrades.

When you draft each plan card, write the audience line first. A sentence such as "For solo founders shipping one product" or "For teams that need shared queues and audit logs" tells a skimming buyer whether to keep reading. Then list the hard limit that most often decides the purchase - seats, projects, messages, or storage - before any soft perk. Soft perks belong lower on the card or in the comparison table so they do not hide the constraint that will matter at renewal.

If your checkout uses annual prepay, show the monthly equivalent next to the annual total so buyers can compare without a calculator. Match those numbers to the Stripe or billing product IDs your app already uses. A pricing page that promises $29 while checkout charges $39 creates support tickets and chargebacks. Review the page whenever you change a meter, add a plan, or end a promotional price, and note the change date in a short changelog line near the bottom.