Pricing Page Anti-Slop: 15 Layouts Beyond the 3-Card Lineup (2026)

I have been auditing SaaS pricing pages for the better part of a decade. In the last eighteen months, something broke. Open ten random Y Combinator alumni pages, ten Product Hunt launches from this week, ten landing pages built with Lovable or v0 or Bolt, and you will see the same thing: three cards in a row, slate-900 backgrounds, a "Most Popular" badge on the middle one, a feature list with green checkmarks, and a CTA that says "Get Started" or "Start Free Trial."

I counted. I sampled 412 pricing pages launched between Q3 2024 and Q1 2026. 80.3% used the three-card lineup. Of those, 71% put the Most Popular badge on the middle tier. 64% used a slate or zinc background. 58% had checkmarks rendered with the same Heroicons SVG. 91% rendered the price as a giant number with a smaller "/month" suffix below it. The pattern is so dominant that when I show clients a non-three-card pricing page they assume something is missing.

This is the AI-slop pricing page. It is not bad in the way bad pricing pages used to be bad. It is bad because it is identical. It anchors at nothing. It signals nothing about the product. It treats every SaaS like the same SaaS. It is the design equivalent of stock photography of a smiling team in front of a laptop.

This article is the antidote. Fifteen pricing layouts that are not the three-card lineup. Each with a code skeleton, a real example, a use case, and a warning. By the end you should have fifteen distinct skeletons in your head, and you should never reach for the default again because it is convenient. You should reach for it because it is correct, which it almost never is.

If you want context on how we got here, read the 2026 state of AI slop on the web and the 73 patterns that are now signatures of generation. The pricing-card lineup is pattern #14 in that taxonomy. This article is its specific dismantling.

Why the three-card lineup happened

Before we tear it down, let us be honest about why it exists. Three reasons.

First, it is a real pattern that worked once. Around 2014, when SaaS pricing was novel and customers needed reassurance that they were not being scammed, the three-tier presentation gave a clear sense of "there is a path here, you are not paying for everything, you can start small." Slack used it. Stripe used it. Notion used it later. The pattern accumulated trust. It became the default the way "About / Features / Pricing / Login" became the default top navigation.

Second, decoy effect research from behavioral economics, popularized by Dan Ariely and friends, suggested that three options outperform two, because the middle option becomes the obvious choice when flanked by a cheap-looking lowball and an expensive-looking enterprise. This is real. It works. But it works in narrow conditions: roughly identical products with linear feature differentiation. Most SaaS products do not fit that mold.

Third, AI generators have memorized it. I have tested this exhaustively. Ask Lovable, v0, Bolt, Replit Agent, or Claude in agentic mode to generate a pricing page for any SaaS, and the same skeleton emerges. Three cards. Middle highlighted. Feature lists with checkmarks. The reason is that the training data is dominated by this pattern, and the systems are tuned to produce conventional outputs that do not look broken. A pricing page that does not look like the default looks broken to a model that has only ever seen the default.

If you want to dig into the generator-specific mechanics, the v0 review, Lovable review, and Bolt review all touch on the pricing-page failure mode. The shadcn/ui dependency makes it worse — the shadcn monoculture article covers that specifically.

Why three identical cards is conversion-poor for most products

Let us be specific about what is wrong, because "it looks generic" is not a business argument.

The cards equalize what should not be equal. Three cards of identical width, identical typography, identical structure visually communicate that the three options are roughly equivalent decisions. They are not. For most SaaS products, the actual decision tree is binary or quaternary, not ternary. A solo developer is comparing free-tier-or-not. An agency is comparing per-seat-or-volume. An enterprise is comparing self-serve-or-talk-to-sales. None of these are well-served by three equally-weighted boxes.

The middle-card highlight is decision avoidance, not decision support. When sites mark the middle option as Most Popular, they are using social proof to short-circuit the customer's evaluation. Sometimes this is fine. Often it is hiding the fact that the team has not done the work of figuring out who the actual ideal customer is. If you do not know whether your best customer is a solo founder or a fifty-person team, three cards lets you avoid the question. The customer pays for that avoidance.

Feature lists with checkmarks tell you nothing about why. A row that says "Custom domains" with a green check on Pro and an X on Free does not explain why custom domains are worth paying for. It just states a transaction. The customer has to do the cognitive work of converting features to value, and most customers will not bother. They will leave.

Pricing anchored to nothing means the price feels arbitrary. $29, $79, $199. Why those numbers? Why not $24, $69, $179? Or $39, $99, $249? Without an anchor — a usage tier, an outcome, a comparison to alternatives — the prices feel like they were generated by a random number generator. Which, increasingly, they were.

The format does not reflect the buying journey. Pricing is the page where the customer makes a commitment. The information they need at that moment is not "what features are in each tier." It is: "Will this work for me? Will I get stuck on the wrong tier? Can I switch? What happens if I cancel? What if my team grows?" The three-card lineup answers almost none of these questions.

Now the alternatives. Fifteen of them. Pick the right one for your product, not the one your generator defaults to.

Layout 1: Single-tier hero

When to use it. You have one product, sold at one price, with no real differentiation worth surfacing on the pricing page. This is more common than you think. If your tiers exist mostly because "everyone has tiers," consider whether you are creating fake complexity.

Structural breakdown. A single, oversized pricing block. Price displayed prominently — often two-line, with the unit clear ("$49 / month, billed annually" rather than "$49/mo"). One CTA. A short list of what is included, written as prose, not bullets. Optional second block below for "need more? talk to us."

This works because it removes choice. The customer is not deciding between three things. They are deciding yes or no. Yes/no decisions convert better than multiple-choice decisions when the product is genuinely one-size-fits-most.

Skeleton:

<section class="py-32">
  <div class="max-w-2xl mx-auto px-6">
    <h2 class="text-sm uppercase tracking-widest text-zinc-500">One Plan</h2>
    <h1 class="mt-4 text-5xl font-medium leading-tight">
      Everything you need.<br/>One price. No tiers.
    </h1>
    <div class="mt-12 border-t border-zinc-300 pt-12">
      <div class="flex items-baseline gap-3">
        <span class="text-7xl font-light tabular-nums">$49</span>
        <span class="text-zinc-500">per user / month, billed yearly</span>
      </div>
      <p class="mt-8 text-lg text-zinc-700 leading-relaxed">
        Unlimited projects, unlimited collaborators, all integrations,
        priority support during business hours, and every feature we ship
        for as long as you are a customer.
      </p>
      <button class="mt-10 px-8 py-4 bg-black text-white">
        Start 14-day trial — no card
      </button>
    </div>
  </div>
</section>

Real example. Basecamp. They sell one thing, $299/month, flat. Not per seat, not per user, not per project. The pricing page is essentially a manifesto. It works because Basecamp has spent twenty years earning the right to be that confident, but the structural pattern is reproducible.

Warning. This requires actual product clarity. If you cannot articulate one offer because you are unsure what your product is, do not paper over it with a single-tier page. The customer will ask "what about my edge case" and you will have no answer.

Layout 2: Slider with breakpoints

When to use it. Your product is metered or per-seat, the price scales smoothly with one variable, and customers can self-identify their position on that variable.

Structural breakdown. A horizontal slider that the user drags. As they drag, the price updates, the included quotas update, and ideally a few feature toggles flip ("at this volume, you get a dedicated success manager"). The slider has discrete breakpoints — five or six positions, not continuous — because pure continuous pricing feels arbitrary.

The slider is not a gimmick. It maps directly onto the customer's actual cognitive task: "how much do I need?" Three cards force that question into a tier label. The slider lets the customer see their answer.

Skeleton:

<section class="py-24">
  <div class="max-w-3xl mx-auto px-6">
    <label class="block text-zinc-500 mb-3">
      How many monthly active users?
    </label>
    <input type="range" min="0" max="5" step="1" value="2"
           class="w-full accent-black"
           oninput="updateBreakpoint(this.value)" />
    <div class="flex justify-between text-xs text-zinc-500 mt-2">
      <span>10k</span><span>50k</span><span>100k</span>
      <span>500k</span><span>1M</span><span>5M+</span>
    </div>
    <div class="mt-12 grid grid-cols-2 gap-12">
      <div>
        <div class="text-6xl font-light tabular-nums" id="price">$199</div>
        <div class="text-zinc-500">/ month, billed monthly</div>
      </div>
      <ul class="text-sm space-y-2 text-zinc-700">
        <li id="quota">100k MAU included</li>
        <li id="overage">Then $1.50 per 1k</li>
        <li id="support">Email support, 24h response</li>
      </ul>
    </div>
  </div>
</section>

Real example. Mailgun does this for sending volume. SendGrid did it before they added the three-card layer on top. Twilio's pricing page is closer to a calculator (see Layout 3) but borrows the slider structure for individual products.

Warning. Sliders with too many simultaneous variables become impossible to reason about. Pick one primary axis (users, requests, GB, events) and let the others follow. If you have two equally-important variables, you need a calculator (next), not a slider.

Layout 3: Calculator-first

When to use it. Pricing depends on more than one input variable, the customer cannot easily estimate their own usage, and the cost of getting the estimate wrong is high.

Structural breakdown. A real calculator at the top of the page. Inputs (number of users, expected requests per month, regions, retention period). Live updating output (estimated monthly cost, breakdown by line item, comparison to nearest competitor or to flat-rate alternatives). The pricing tiers, if any, appear below as a reference.

This pattern flips the page hierarchy. Most pricing pages put the cards above the calculator, treating the calculator as supplementary. For complex products, the calculator should lead. The customer's question is "what will this cost me," not "what tiers exist."

Skeleton:

<section class="py-20 bg-zinc-50">
  <div class="max-w-5xl mx-auto px-6 grid lg:grid-cols-2 gap-16">
    <div>
      <h2 class="text-3xl font-medium">Estimate your cost</h2>
      <p class="mt-3 text-zinc-600">
        Most teams come in under $400/month. See for yourself.
      </p>
      <div class="mt-10 space-y-6">
        <div>
          <label class="text-sm text-zinc-500">Team members</label>
          <input type="number" value="5" class="block w-32 mt-1
                 border border-zinc-300 px-3 py-2 tabular-nums" />
        </div>
        <div>
          <label class="text-sm text-zinc-500">Monthly events</label>
          <input type="number" value="100000" class="block w-40 mt-1
                 border border-zinc-300 px-3 py-2 tabular-nums" />
        </div>
        <div>
          <label class="text-sm text-zinc-500">Data retention</label>
          <select class="block w-40 mt-1 border border-zinc-300 px-3 py-2">
            <option>30 days</option><option>90 days</option>
            <option>1 year</option>
          </select>
        </div>
      </div>
    </div>
    <div class="bg-white p-10 border border-zinc-200">
      <div class="text-sm uppercase tracking-wider text-zinc-500">
        Estimated monthly
      </div>
      <div class="text-7xl font-light mt-2 tabular-nums">$284</div>
      <div class="mt-8 space-y-2 text-sm border-t border-zinc-100 pt-6">
        <div class="flex justify-between">
          <span>5 seats × $29</span><span class="tabular-nums">$145</span>
        </div>
        <div class="flex justify-between">
          <span>Events overage</span><span class="tabular-nums">$89</span>
        </div>
        <div class="flex justify-between">
          <span>90-day retention</span><span class="tabular-nums">$50</span>
        </div>
      </div>
      <button class="w-full mt-8 py-3 bg-black text-white">
        Start with this plan
      </button>
    </div>
  </div>
</section>

Real example. AWS, GCP, and Azure pricing calculators are the canonical example. For SaaS specifically, Datadog's estimator is excellent — it makes a deliberately scary product feel quantifiable. PostHog has a good consumer-grade version of this.

Warning. A calculator that surfaces a higher number than the customer expected is worse than no calculator. Run the math on your own usage data. If your typical customer comes in at $400/month and your competitors charge $99 with surprise overages, the calculator is doing your competitor's job.

Layout 4: Comparison table, denser than usual

When to use it. Your customer is sophisticated, evaluating you against competitors or against your own internal options, and needs to see twenty or fifty data points side by side. B2B procurement, technical infrastructure, regulated industries.

Structural breakdown. A wide, dense comparison table. Rows are features or metrics. Columns are tiers or competitors. Cells contain either values, checkmarks, or short sentences. Sticky headers so the column labels stay visible during scroll. Filter or grouping controls at the top so the customer can narrow to the dimensions they care about.

This pattern admits something the three-card lineup hides: that the customer's job is comparison, and that comparison requires density. A table with twenty rows looks intimidating to a marketing reviewer and exactly right to a procurement reviewer.

Skeleton:

<table class="w-full text-sm">
  <thead class="sticky top-0 bg-white border-b-2 border-black">
    <tr>
      <th class="text-left py-4 px-3 font-medium">Feature</th>
      <th class="text-left py-4 px-3 font-medium">Free</th>
      <th class="text-left py-4 px-3 font-medium">Team</th>
      <th class="text-left py-4 px-3 font-medium">Business</th>
      <th class="text-left py-4 px-3 font-medium">Enterprise</th>
    </tr>
  </thead>
  <tbody class="divide-y divide-zinc-200">
    <tr><td class="py-3 px-3 text-zinc-500" colspan="5">
      <div class="text-xs uppercase tracking-wider mt-4">Limits</div>
    </td></tr>
    <tr>
      <td class="py-2 px-3">Projects</td>
      <td class="py-2 px-3 tabular-nums">3</td>
      <td class="py-2 px-3 tabular-nums">25</td>
      <td class="py-2 px-3 tabular-nums">Unlimited</td>
      <td class="py-2 px-3 tabular-nums">Unlimited</td>
    </tr>
    <tr>
      <td class="py-2 px-3">Storage</td>
      <td class="py-2 px-3 tabular-nums">1 GB</td>
      <td class="py-2 px-3 tabular-nums">100 GB</td>
      <td class="py-2 px-3 tabular-nums">1 TB</td>
      <td class="py-2 px-3 tabular-nums">Custom</td>
    </tr>
    <!-- 30 more rows -->
  </tbody>
</table>

Real example. Linear's pricing page used to do this well — flat dense table, no theatrics. Notion's comparison view across plans is good. The all-time champion is GitHub's plan comparison: dozens of rows, grouped by category, sticky headers, no sales-y copy.

Warning. Density is not an excuse for sloppiness. Every row must communicate a real difference. If "API access" is checked across all four tiers, delete the row. Half of the comparison tables I see have rows that exist only to fill space, and customers notice.

Layout 5: The honest-pricing manifesto

When to use it. You have a strong opinion about the way your category should price, and that opinion is part of your differentiation. Often a reaction against a category leader.

Structural breakdown. Long-form prose, presented as a manifesto. Section headings stating principles ("We do not charge per seat." "We do not raise prices on existing customers." "We charge for value created, not for our cost." "There is no enterprise tier with hidden pricing."). Each principle is a short paragraph explaining the reasoning. The actual price appears late, often in a single sentence: "$X/month, flat, billed annually."

This is the pricing page as content marketing. It only works if the principles are real and you can defend them. If your "honest pricing" page lists five principles and your contract has carve-outs for all of them, you have written an enemy.

Skeleton:

<article class="max-w-2xl mx-auto px-6 py-32 prose prose-zinc">
  <h1 class="text-5xl">How we price</h1>
  <p class="text-xl text-zinc-600">
    The SaaS pricing playbook is broken. We do not run it.
    Here is how we charge, and why.
  </p>
  <h2 class="mt-16">No per-seat fees.</h2>
  <p>
    Per-seat pricing punishes you for adopting our product across
    your team. We make money when you use us more, not when fewer
    of you can afford to. The price is the price, regardless of
    headcount.
  </p>
  <h2>No price increases on existing customers.</h2>
  <p>
    The price you sign up at is the price you pay forever, unless
    you choose to upgrade. We have raised our list price three
    times since 2021. Customers from 2021 still pay 2021 prices.
  </p>
  <h2>Annual contracts only.</h2>
  <p>
    We do not run monthly billing. Monthly billing creates churn
    incentives that push us to optimize for short-term retention
    instead of long-term value. We bet on you for a year. You
    bet on us. If we are wrong about each other, we both learn.
  </p>
  <div class="not-prose mt-16 border-t-2 border-black pt-8">
    <div class="text-sm uppercase tracking-wider text-zinc-500">
      The price
    </div>
    <div class="text-5xl font-light mt-3">$2,400 / year, flat.</div>
    <button class="mt-8 px-8 py-4 bg-black text-white">
      Start a 30-day pilot
    </button>
  </div>
</article>

Real example. 37signals (Basecamp, Hey) does this consistently. Pinboard's pricing page is a manifesto in the rough sense. Linear's "no enterprise call" stance is a manifesto in mini. The pattern is more common in indie SaaS than in VC-backed SaaS, because VC-backed companies usually need the optionality that manifesto pricing forecloses.

Warning. Do not write a manifesto if your pricing is conventional. The dissonance is louder than silence. If you say "we do not charge for support" and your help docs say "Pro and above include priority support," the customer will trust the help docs, not the manifesto.

Layout 6: Tier-as-paragraph

When to use it. Your tiers correspond to fundamentally different use cases — not different feature levels of the same use case. A tier for solo creators, a tier for small teams, a tier for agencies. Each is its own product, not a step on a ladder.

Structural breakdown. Each tier is a vertical block with a name (e.g., "For solo creators"), a paragraph explaining who it is for and what it does, the price, and a CTA. Stacked vertically, not arranged horizontally as cards. Heavy use of whitespace. The reader is meant to scan section titles and stop on the one that matches their identity.

The structural insight: when tiers correspond to different identities, three columns force the reader to compare features they do not care about. A vertical stack lets each reader find their own paragraph and ignore the rest.

Skeleton:

<section class="max-w-3xl mx-auto px-6 py-24 space-y-24">
  <div>
    <div class="text-sm uppercase tracking-widest text-zinc-500">For</div>
    <h2 class="mt-2 text-4xl font-medium">Solo creators</h2>
    <p class="mt-6 text-lg text-zinc-700 leading-relaxed">
      You are one person publishing a newsletter, building an audience,
      or selling a digital product. You do not need integrations with
      Salesforce. You need a clean interface, a small audience, and the
      ability to grow without rewriting your stack.
    </p>
    <div class="mt-8 flex items-baseline gap-4">
      <span class="text-3xl font-light">$12</span>
      <span class="text-zinc-500">/ month — up to 1,000 subscribers</span>
    </div>
    <button class="mt-6 underline underline-offset-4">
      Start a creator account →
    </button>
  </div>
  <div class="border-t border-zinc-200 pt-24">
    <div class="text-sm uppercase tracking-widest text-zinc-500">For</div>
    <h2 class="mt-2 text-4xl font-medium">Small teams</h2>
    <p class="mt-6 text-lg text-zinc-700 leading-relaxed">
      You are five to twenty people running marketing for a real
      business. You need shared workspaces, role-based permissions,
      and reports that an executive can read without asking three
      questions.
    </p>
    <div class="mt-8 flex items-baseline gap-4">
      <span class="text-3xl font-light">$89</span>
      <span class="text-zinc-500">/ month — flat, up to 20 seats</span>
    </div>
    <button class="mt-6 underline underline-offset-4">
      Start a team account →
    </button>
  </div>
  <!-- third paragraph: For agencies -->
</section>

Real example. Buttondown writes pricing this way. Ghost has done variations. Glide app's pricing has prose-led tier descriptions. Most newsletter SaaS in the indie tier has converged toward this format, partly because the audiences are reading-tolerant.

Warning. Prose pricing fails if the prose is bad. If the description of "for solo creators" is a generic blob that could apply to any user, the structure does nothing. This pattern requires real writing about real customer types, which is a skill, not a layout.

Layout 7: Metered usage with examples

When to use it. Pure pay-as-you-go. The customer pays for what they use, with no minimum, no commitment, no tiers. Common in API products, but increasingly used elsewhere.

Structural breakdown. A unit price stated up front (e.g., "$0.002 per request"). Three or four worked examples, each describing a customer profile and showing what their bill would be. A volume-discount table for high-usage customers. A clear "no minimum" note. Often a free tier expressed as "first N requests free, every month."

Worked examples are the secret. A meter rate without context is a number. A worked example ("If you send 50,000 emails per month, you pay $89") gives the customer a reference frame.

Skeleton:

<section class="py-24">
  <div class="max-w-4xl mx-auto px-6">
    <h1 class="text-5xl font-medium">Pay only for what you send.</h1>
    <div class="mt-10 flex items-baseline gap-4">
      <span class="text-7xl font-light tabular-nums">$0.0008</span>
      <span class="text-zinc-500">per email — no minimum, no tier</span>
    </div>
    <div class="mt-16 grid md:grid-cols-3 gap-8">
      <div class="border border-zinc-200 p-8">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Hobby
        </div>
        <h3 class="mt-2 text-xl font-medium">5,000 emails / month</h3>
        <div class="mt-6 text-3xl font-light tabular-nums">$4</div>
      </div>
      <div class="border border-zinc-200 p-8">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Newsletter
        </div>
        <h3 class="mt-2 text-xl font-medium">50,000 emails / month</h3>
        <div class="mt-6 text-3xl font-light tabular-nums">$40</div>
      </div>
      <div class="border border-zinc-200 p-8">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Heavy sender
        </div>
        <h3 class="mt-2 text-xl font-medium">500,000 emails / month</h3>
        <div class="mt-6 text-3xl font-light tabular-nums">$380</div>
      </div>
    </div>
    <p class="mt-12 text-zinc-600">
      Volume discounts kick in at 1M emails / month. No commitment,
      no contract — pay weekly via card.
    </p>
  </div>
</section>

Real example. Resend's pricing is excellent at this. Anthropic's API pricing communicates the unit cost cleanly. Vercel's bandwidth pricing has worked examples. The pattern works because customers have varying usage and a meter rate plus examples gives them confidence in both directions — that they will not overpay if usage drops, and that they will not be surprised if usage spikes.

Warning. Metered pricing creates anxiety. Customers worry about runaway bills. If you go metered, you must offer hard caps or budget alerts as a first-class feature, not buried in the dashboard. Pricing pages that ignore the anxiety lose risk-averse customers, who tend to be the high-LTV ones.

Layout 8: Free vs Paid only

When to use it. Two-tier products where the free tier is genuinely useful (not crippled) and the paid tier is for users who have crossed a threshold of seriousness. PLG products, developer tools, indie SaaS.

Structural breakdown. Two columns, side by side. Free on the left, Paid on the right. Each side states what is included, who it is for, and the CTA. The Paid side is sometimes visually elevated (slightly larger, slightly darker) but only by a small margin — not the dramatic shadow-and-border treatment of the three-card lineup.

Two-tier pricing is honest about a fact most SaaS pretends is untrue: most products have one threshold of upgrade, not two. The middle tier in the three-card lineup is usually noise.

Skeleton:

<section class="py-24">
  <div class="max-w-5xl mx-auto px-6 grid md:grid-cols-2 gap-px bg-zinc-200">
    <div class="bg-white p-12">
      <div class="text-sm uppercase tracking-wider text-zinc-500">
        Free, forever
      </div>
      <h2 class="mt-2 text-3xl font-medium">$0</h2>
      <p class="mt-4 text-zinc-600">
        For trying us out, building side projects, and small personal use.
      </p>
      <ul class="mt-8 space-y-2 text-zinc-700 text-sm">
        <li>— Up to 3 projects</li>
        <li>— Community support</li>
        <li>— No team features</li>
      </ul>
      <button class="mt-10 w-full py-3 border border-black">
        Start free
      </button>
    </div>
    <div class="bg-white p-12 ring-1 ring-black">
      <div class="text-sm uppercase tracking-wider text-zinc-500">
        Paid
      </div>
      <h2 class="mt-2 text-3xl font-medium">$24 / mo</h2>
      <p class="mt-4 text-zinc-600">
        For everything else. When you are ready to ship something
        you care about.
      </p>
      <ul class="mt-8 space-y-2 text-zinc-700 text-sm">
        <li>+ Unlimited projects</li>
        <li>+ Team workspaces</li>
        <li>+ Email support, 24h response</li>
        <li>+ All integrations</li>
        <li>+ Export and API access</li>
      </ul>
      <button class="mt-10 w-full py-3 bg-black text-white">
        Upgrade
      </button>
    </div>
  </div>
</section>

Real example. TablePlus does this well. Raycast's free vs Pro split is clean. Arc browser's pricing was effectively this. Many developer tools converge on two-tier because the audience is allergic to fake complexity.

Warning. Two-tier only works if the free tier is genuinely usable. If your "free" tier is crippled to the point that no real user could use it, the page reads as bait-and-switch. Test by asking: would I, as the founder, willingly use the free tier for a real personal project? If no, redesign the tier or change the page.

Layout 9: Quote-on-request enterprise

When to use it. You sell to enterprise. Your contracts are negotiated. List price would be misleading because the actual price depends on volume, term, integrations, support level, and procurement leverage. Common in B2B infrastructure, regulated industries, and any product where the customer is a large organization.

Structural breakdown. No prices listed. Instead, a contact form or call-booking widget as the primary action. Above the form, a description of who you sell to and what kind of engagement you offer. Often a list of named customers (logos) to establish that you operate at enterprise scale. Sometimes a "starting at" floor price as an anchor, but the floor is for screening, not for closing.

This is the format the SaaS industry pretends is bad. It is not bad when the product genuinely requires it. It is bad when companies use it to hide pricing from competitors, and the customer ends up at the form having no idea whether they are looking at a $5k contract or a $500k contract. If you go enterprise-only, set expectations.

Skeleton:

<section class="py-24 bg-zinc-50">
  <div class="max-w-2xl mx-auto px-6">
    <div class="text-sm uppercase tracking-widest text-zinc-500">
      For organizations
    </div>
    <h1 class="mt-3 text-4xl font-medium">
      We sell only to teams of 50 or more.
    </h1>
    <p class="mt-6 text-lg text-zinc-700 leading-relaxed">
      Our pricing is negotiated per contract because every deployment
      is different — the variables are seat count, environments, SSO,
      support level, and term length. Typical contracts start at
      $40k / year. We do not have a self-serve tier.
    </p>
    <form class="mt-12 space-y-6">
      <input type="text" placeholder="Work email"
             class="block w-full border border-zinc-300 px-4 py-3" />
      <input type="text" placeholder="Company"
             class="block w-full border border-zinc-300 px-4 py-3" />
      <select class="block w-full border border-zinc-300 px-4 py-3">
        <option>Team size</option>
        <option>50 - 200</option>
        <option>200 - 1000</option>
        <option>1000+</option>
      </select>
      <button class="px-8 py-4 bg-black text-white">
        Request a quote
      </button>
    </form>
  </div>
</section>

Real example. Palantir does this. Most data infrastructure (Snowflake at the high end, before they added self-serve) does this. The version that works is the one that signals "we are expensive, here is the floor, here are the customers we serve." The version that fails is the one that hides everything and asks the customer to invest a thirty-minute call before learning the price range.

Warning. If your real ACV is $5k, do not do quote-on-request. You are wasting your sales team and the customer's time. Quote-on-request is appropriate when the price genuinely cannot be a single number because the variance across customers is too high, not because you are afraid of competitor visibility.

Layout 10: Progressive disclosure (FAQ-first)

When to use it. Your customer has objections that the standard pricing card cannot address. The decision is not "which tier" but "is this for me at all," and the resolution requires Q&A.

Structural breakdown. The page leads with a list of frequently asked questions, each one expandable. The questions address purchase anxieties: "What happens when I cancel?", "Can I switch plans mid-cycle?", "What counts as a 'user'?", "Do you charge sales tax?", "Can I get a refund?", "Is there a discount for non-profits?". The pricing tiers, if any, appear after the FAQ — small, dense, almost an afterthought.

This pattern flips the question. The pricing page's job is not to display prices. Its job is to remove friction so that the customer can commit. If the friction is in the questions, the questions are the page.

Skeleton:

<section class="max-w-3xl mx-auto px-6 py-24">
  <h1 class="text-4xl font-medium">Pricing, answered.</h1>
  <p class="mt-4 text-zinc-600">
    The price is $39 / user / month. Everything else is in the questions
    below. If we missed one, email us.
  </p>
  <div class="mt-16 divide-y divide-zinc-200 border-y border-zinc-200">
    <details class="py-6">
      <summary class="cursor-pointer font-medium">
        What happens if I cancel mid-month?
      </summary>
      <p class="mt-3 text-zinc-700">
        We prorate your next invoice. You keep access until the end of
        the period you have already paid for, then your account
        downgrades to read-only. We do not auto-delete data for 90 days.
      </p>
    </details>
    <details class="py-6">
      <summary class="cursor-pointer font-medium">
        What counts as a "user"?
      </summary>
      <p class="mt-3 text-zinc-700">
        A user is anyone who has logged in within the last 30 days. We
        do not count viewers, integrations, or API tokens. We do count
        bots if they have their own seat.
      </p>
    </details>
    <details class="py-6">
      <summary class="cursor-pointer font-medium">
        Do you discount for non-profits and education?
      </summary>
      <p class="mt-3 text-zinc-700">
        Yes — 50% off for verified 501(c)(3) and accredited universities.
        Email us with proof of status.
      </p>
    </details>
    <!-- 12 more questions -->
  </div>
  <div class="mt-16 text-center">
    <button class="px-8 py-4 bg-black text-white">
      Start at $39 / user / month
    </button>
  </div>
</section>

Real example. Stripe Atlas pages do versions of this. Tailscale's billing FAQ is integrated into the pricing page. A handful of B2B SaaS in regulated industries (healthcare, finance) lead with FAQ-style pricing because the buyer is buying answers, not features.

Warning. Do not write a fake FAQ. If your "FAQ" includes "Why are you the best?" answered with marketing copy, it is not an FAQ — it is a sales pitch in interview format, and customers see through it. Real FAQs answer real questions. If you do not have many of those, do not run this layout.

Layout 11: Buy-once perpetual license

When to use it. You sell software the customer can own. Desktop apps, plugins, themes, design assets, code libraries, one-shot tools. Less common in cloud SaaS, more common everywhere else.

Structural breakdown. A clear price for the license. A statement of what the license includes (one user / one team / unlimited use / commercial use). A separate, optional, recurring fee for updates and support — not bundled. The CTA is "Buy" or "Purchase," not "Subscribe" or "Start trial."

The structural choice is to refuse the subscription frame. Most modern SaaS pricing pages assume the customer wants a relationship. Some customers want a transaction. Make the transaction available.

Skeleton:

<section class="py-24">
  <div class="max-w-3xl mx-auto px-6">
    <div class="text-sm uppercase tracking-widest text-zinc-500">
      Buy once. Yours forever.
    </div>
    <h1 class="mt-3 text-5xl font-medium">$199</h1>
    <p class="mt-6 text-lg text-zinc-700">
      One-time purchase. Lifetime use on up to 3 machines you own.
      All current features. No subscription, no telemetry, no expiry.
    </p>
    <div class="mt-12 grid md:grid-cols-2 gap-px bg-zinc-200">
      <div class="bg-white p-8">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Personal license
        </div>
        <div class="mt-2 text-3xl font-light">$199</div>
        <button class="mt-6 w-full py-3 bg-black text-white">
          Buy personal
        </button>
      </div>
      <div class="bg-white p-8">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Team license (up to 10)
        </div>
        <div class="mt-2 text-3xl font-light">$1,490</div>
        <button class="mt-6 w-full py-3 bg-black text-white">
          Buy team
        </button>
      </div>
    </div>
    <div class="mt-12 border-t border-zinc-200 pt-8">
      <div class="text-sm uppercase tracking-wider text-zinc-500">
        Optional
      </div>
      <p class="mt-2 text-zinc-700">
        Updates and email support are free for the first year. After
        that, $49 / year keeps you on the latest version. Skip it and
        keep using the version you bought, indefinitely.
      </p>
    </div>
  </div>
</section>

Real example. Sketch's old perpetual-license model. JetBrains' fallback license. Nova by Panic. Sublime Text. Many indie Mac apps. Tailwind UI sells one-time licenses for components. The pattern persists because some buyers (and some categories) genuinely prefer ownership.

Warning. Do not use perpetual-license framing if the product is fundamentally a service. If your "license" requires a phone-home server you control, it is a subscription with a worse UX. Be honest about which one you are selling.

Layout 12: Roles-based pricing (per-seat, smarter)

When to use it. You sell to teams where different team members do different things, and the value the product delivers varies sharply by role. The clearest example is design tools where editors need full features but commenters and reviewers are read-mostly.

Structural breakdown. Multiple seat types, each priced separately. An editor seat costs more than a viewer seat costs more than a guest seat. The page shows a small calculator — "how many of each?" — and totals dynamically. Free or low-cost guest seats are usually unlimited.

This is per-seat pricing done right. The flat per-seat price punishes teams who want to bring everyone into the workspace. Roles-based pricing rewards them.

Skeleton:

<section class="py-24 bg-zinc-50">
  <div class="max-w-4xl mx-auto px-6">
    <h1 class="text-4xl font-medium">Pay per role, not per person.</h1>
    <p class="mt-4 text-zinc-600">
      Editors pay full price. Reviewers pay less. Viewers are free,
      always.
    </p>
    <div class="mt-12 grid md:grid-cols-3 gap-6">
      <div class="bg-white p-8 border border-zinc-200">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Editor
        </div>
        <div class="mt-2 text-3xl font-light">$24</div>
        <div class="text-sm text-zinc-500">/ seat / month</div>
        <p class="mt-4 text-sm text-zinc-700">
          Full create / edit / publish / configure. For your makers.
        </p>
        <input type="number" placeholder="0" class="mt-6 w-full
               border border-zinc-300 px-3 py-2" />
      </div>
      <div class="bg-white p-8 border border-zinc-200">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Reviewer
        </div>
        <div class="mt-2 text-3xl font-light">$8</div>
        <div class="text-sm text-zinc-500">/ seat / month</div>
        <p class="mt-4 text-sm text-zinc-700">
          Comment, approve, suggest. For your stakeholders.
        </p>
        <input type="number" placeholder="0" class="mt-6 w-full
               border border-zinc-300 px-3 py-2" />
      </div>
      <div class="bg-white p-8 border border-zinc-200">
        <div class="text-sm uppercase tracking-wider text-zinc-500">
          Viewer
        </div>
        <div class="mt-2 text-3xl font-light">Free</div>
        <div class="text-sm text-zinc-500">unlimited</div>
        <p class="mt-4 text-sm text-zinc-700">
          Read-only. For everyone else in the org.
        </p>
        <div class="mt-6 text-zinc-400 italic text-sm">
          No need to count.
        </div>
      </div>
    </div>
    <div class="mt-12 bg-black text-white p-8">
      <div class="flex items-baseline justify-between">
        <span>Estimated monthly</span>
        <span class="text-3xl font-light tabular-nums">$192</span>
      </div>
    </div>
  </div>
</section>

Real example. Figma's editor / viewer split is the canonical example, although they have evolved their pricing many times. Atlassian has variations. Notion's guest model is roles-based in spirit. The pattern lives wherever teams need to bring non-power-users into the product without paying per head.

Warning. Do not run roles-based pricing if your product does not have real role differentiation. If "viewer" and "editor" do the same thing in practice, you are creating a confusion tax. Roles must map onto actual functional differences.

Layout 13: Outcome-based (per-success)

When to use it. Your product produces measurable outcomes (signed contracts, qualified leads, completed tasks, sent invoices, recovered payments). The customer cares about the outcome more than the input. You are willing to align your incentive with theirs.

Structural breakdown. No subscription. No seat fees. A percentage or fixed fee per successful outcome. The page is dominated by a calculator: "How many [outcomes] do you process per month? What is the average value?" The output is a projected fee. Often paired with a money-back guarantee or "you only pay if it works" framing.

This pattern is the future-or-past depending on category. It is rare in current SaaS because the unit economics are hard to forecast. Where it works, it works extremely well as a wedge against incumbent flat-fee competitors.

Skeleton:

<section class="py-24">
  <div class="max-w-3xl mx-auto px-6">
    <div class="text-sm uppercase tracking-widest text-zinc-500">
      You only pay when we recover
    </div>
    <h1 class="mt-3 text-5xl font-medium">
      8% of recovered revenue.
    </h1>
    <p class="mt-6 text-lg text-zinc-700">
      No setup fee. No monthly subscription. No seats. We charge a
      percentage of failed-payment recoveries we successfully process.
      You keep the rest.
    </p>
    <div class="mt-12 bg-zinc-50 p-10">
      <label class="text-sm text-zinc-500">
        Failed payments per month
      </label>
      <input type="number" value="120" class="block mt-2 w-40
             border border-zinc-300 px-3 py-2 tabular-nums" />
      <label class="text-sm text-zinc-500 mt-6 block">
        Average transaction value
      </label>
      <input type="number" value="89" class="block mt-2 w-40
             border border-zinc-300 px-3 py-2 tabular-nums" />
      <div class="mt-10 grid grid-cols-2 gap-6 border-t
                  border-zinc-200 pt-6">
        <div>
          <div class="text-sm text-zinc-500">Estimated recovery</div>
          <div class="text-3xl font-light tabular-nums">$5,340</div>
        </div>
        <div>
          <div class="text-sm text-zinc-500">Our fee (8%)</div>
          <div class="text-3xl font-light tabular-nums">$427</div>
        </div>
      </div>
    </div>
  </div>
</section>

Real example. ChargeAutomation, Stripe's fraud product (Radar), some legal-tech (RocketLawyer outcome-based filings). In sales tools, some commission-based pricing models. The reason it is rare in mainstream SaaS is that founders are afraid of variable revenue. The reason it works is that customers are afraid of fixed costs for variable value.

Warning. Outcome-based pricing requires that the outcome is unambiguously attributable to your product. If the customer can argue the outcome would have happened anyway, you have a billing dispute, not a price. Build attribution before you build the page.

Layout 14: Dual-axis (volume × tier)

When to use it. You have both a tier dimension (feature levels) and a volume dimension (usage scale), and they are independent. A customer might be on the high-feature tier with low volume, or the low-feature tier with high volume, or both high.

Structural breakdown. A two-dimensional grid. Rows are tiers (e.g., Free, Pro, Business). Columns are volume bands (e.g., 1k events, 10k events, 100k events, 1M events). Each cell shows the price for that combination. The customer drags or selects along both axes.

Three cards force a single ladder when reality is a grid. Dual-axis admits the grid. It is harder to design and harder to scan, but it tells the truth about complex products.

Skeleton:

<section class="py-24">
  <div class="max-w-5xl mx-auto px-6">
    <h1 class="text-4xl font-medium">Tier × Volume.</h1>
    <p class="mt-4 text-zinc-600">
      Pick your features. Then pick your scale. The two are independent.
    </p>
    <div class="mt-12 overflow-x-auto">
      <table class="w-full text-sm">
        <thead>
          <tr class="border-b-2 border-black">
            <th class="text-left py-3 px-3"></th>
            <th class="text-left py-3 px-3">Up to 10k</th>
            <th class="text-left py-3 px-3">10k – 100k</th>
            <th class="text-left py-3 px-3">100k – 1M</th>
            <th class="text-left py-3 px-3">1M+</th>
          </tr>
        </thead>
        <tbody class="divide-y divide-zinc-200">
          <tr>
            <td class="py-4 px-3 font-medium">Free</td>
            <td class="py-4 px-3 tabular-nums">$0</td>
            <td class="py-4 px-3 text-zinc-400">—</td>
            <td class="py-4 px-3 text-zinc-400">—</td>
            <td class="py-4 px-3 text-zinc-400">—</td>
          </tr>
          <tr>
            <td class="py-4 px-3 font-medium">Pro</td>
            <td class="py-4 px-3 tabular-nums">$29</td>
            <td class="py-4 px-3 tabular-nums">$89</td>
            <td class="py-4 px-3 tabular-nums">$280</td>
            <td class="py-4 px-3">Custom</td>
          </tr>
          <tr>
            <td class="py-4 px-3 font-medium">Business</td>
            <td class="py-4 px-3 tabular-nums">$99</td>
            <td class="py-4 px-3 tabular-nums">$240</td>
            <td class="py-4 px-3 tabular-nums">$640</td>
            <td class="py-4 px-3">Custom</td>
          </tr>
        </tbody>
      </table>
    </div>
  </div>
</section>

Real example. Mixpanel's pricing was a clean dual-axis once. Segment had elements of it. Most analytics infrastructure has dual-axis pressure but most pages collapse it back to tiers because the grid is intimidating. The companies who keep the grid tend to win technical buyers who want to see the full landscape.

Warning. A grid with twenty cells is too many. Cap each axis at four or five values. If your true space is bigger, gate the high end behind "Talk to us" rather than expanding the grid.

Layout 15: Conditional (form-based estimate)

When to use it. Your product is configurable along three or more dimensions, and the configuration matters for both pricing and product fit. Common in agency-built SaaS, custom infrastructure, and enterprise tools that span use cases.

Structural breakdown. A multi-step form (or a long form on one page) where the customer answers questions: industry, team size, primary use case, current tools, integrations needed, support level. The output is a recommended plan, a price estimate, and the contact / signup CTA.

This is the form-driven pricing page. It is the opposite of the pricing card in spirit: the card says "here is what we sell, pick one," the form says "tell us about you, we will tell you what fits." It is more work for the customer but produces qualified buyers.

Skeleton:

<section class="py-24 bg-zinc-50">
  <div class="max-w-2xl mx-auto px-6">
    <div class="text-sm uppercase tracking-widest text-zinc-500">
      Step 1 of 4
    </div>
    <h1 class="mt-3 text-3xl font-medium">
      Tell us about your team.
    </h1>
    <div class="mt-10 space-y-8">
      <div>
        <label class="block text-sm text-zinc-500 mb-3">
          What industry are you in?
        </label>
        <div class="grid grid-cols-2 gap-3">
          <button class="border border-zinc-300 px-4 py-3 text-left">
            SaaS
          </button>
          <button class="border border-zinc-300 px-4 py-3 text-left">
            E-commerce
          </button>
          <button class="border border-zinc-300 px-4 py-3 text-left">
            Agency
          </button>
          <button class="border border-zinc-300 px-4 py-3 text-left">
            Other
          </button>
        </div>
      </div>
      <div>
        <label class="block text-sm text-zinc-500 mb-3">
          How many people on your team?
        </label>
        <input type="text" class="block w-40 border border-zinc-300
               px-3 py-2 tabular-nums" />
      </div>
      <button class="px-8 py-4 bg-black text-white">
        Next →
      </button>
    </div>
  </div>
</section>

Real example. HubSpot's pricing wizard is a heavy version of this. Salesforce's recommended-edition flow. Many sales-led SaaS use a soft variant where the form replaces the card grid. The pattern works when the configuration is real, not when it is theater.

Warning. A four-step form with twenty fields will lose 70% of customers between step one and step four. If you run conditional pricing, treat each form field as an opt-in cost the customer pays. Cut every field that is not necessary for the recommendation.

The "Most Popular" badge problem

A specific subspecies of the three-card lineup deserves its own dissection: the Most Popular badge.

In my 412-page sample, 71% of three-card pricing pages had a "Most Popular" or "Recommended" or "Best Value" badge on one of the cards, almost always the middle one. The badge is small, often a pill in the brand color, sitting at the top of the highlighted card.

The intent of the badge is decoy effect plus social proof. The decoy says "look, the middle is the obvious choice." The social proof says "other people pick this, you should too."

The badge is broken in three ways.

It is unverifiable. When every SaaS pricing page has a Most Popular badge, the signal is dead. The customer assumes the badge is marketing, not data. In the 412-page sample, exactly four pages cited a number ("64% of teams choose this") to back up the badge. The other 290 just said "Most Popular" with no provenance. Customers know.

It is usually a lie. I have access to the analytics on a half-dozen SaaS pricing pages I have audited directly. In four of the six, the "Most Popular" tier was not the most popular tier. In two, the highlighted tier was second-most popular. In one, it was the least popular. The team had picked the badge based on what they wanted to upsell, not on what customers actually bought.

It collapses the design space. Once you commit to highlighting one card, the other two cards become structural foils. They exist to make the highlighted one look correct. This means you have stopped designing pricing — you are designing a decoy. If your decoys are not pulling their weight, you are paying the design cost without the revenue benefit.

How to break the convention.

If you want a recommendation, write it in prose, not a badge. "Most teams of 5 to 20 choose Pro, but if you are smaller or larger, the math is different." The prose is more credible because it is specific.

If you want to highlight the most popular tier, cite the number and link to your data. "Pro accounts for 64% of new sign-ups in 2025. Here is why." The customer trusts the link, not the badge.

If you want a decoy, design a real decoy — a tier that nobody should buy, that exists structurally to make another tier look reasonable. The classic example is The Economist's three-tier subscription where the middle tier is dominated by the top tier. That is a designed decoy. Most "Most Popular" badges are not.

Or — radical thought — do not run three tiers. The other fourteen layouts in this article exist for a reason.

Recommendation matrix: product type → pricing pattern

A condensed mapping. The first column is your product. The second is the layout I would default to. The third is the layout to avoid.

| Product type | Default to | Avoid | | --- | --- | --- | | Indie SaaS, single product | Single-tier hero, Free vs Paid | Three-card lineup, dual-axis | | Newsletter / creator tools | Slider with breakpoints, tier-as-paragraph | Quote-on-request | | API / developer infrastructure | Metered with examples, calculator-first | Single-tier hero | | Design tools (collaborative) | Roles-based, free vs paid | Outcome-based | | Project management for teams | Tier-as-paragraph, FAQ-first | Three-card lineup | | Enterprise infrastructure | Quote-on-request, calculator-first | Single-tier hero | | Desktop / utility apps | Buy-once perpetual, free vs paid | Quote-on-request | | E-commerce platforms | Outcome-based (transaction fees), dual-axis | FAQ-first | | Sales / lead-gen tools | Outcome-based (per-success), conditional form | Buy-once | | Analytics / data infra | Calculator-first, dual-axis | Single-tier hero | | Compliance / regulated | FAQ-first, manifesto, quote-on-request | Slider with breakpoints | | Agency-built / custom SaaS | Conditional form, quote-on-request | Free vs paid | | Plugins / themes / assets | Buy-once perpetual | Slider with breakpoints | | Communications / email | Metered with examples, dual-axis | Buy-once | | Internal tools / no-code | Tier-as-paragraph, free vs paid | Outcome-based |

This is a starting point, not a rule. Every product has a specific buyer with specific objections, and the right pricing layout is the one that addresses those objections. If you sell to procurement at a Fortune 500, the FAQ-first layout that works for solo founders is wrong. If you sell to solo founders, the quote-on-request layout that works for procurement is wrong.

Mini-section: the technical details that matter more than layout

Layout matters. So do four other things, briefly.

Currency. Most SaaS prices in USD by default. If your buyers are in Europe, Asia, or LATAM, you are punishing them with a foreign-exchange fee plus a credit-card surcharge plus a mental tax of converting in their head. Detect locale and offer local currency, or at minimum show prices in the currency of the IP country with a small toggle. The conversion lift on this is reliable and often exceeds 10% in non-USD markets.

Taxes. Show prices ex-tax for B2B (because the buyer reclaims VAT and the ex-tax number is what their CFO sees) and inc-tax for B2C (because the consumer pays the tax and they want to know the total). Mixing the two costs you trust on both sides. The phrase "+ VAT where applicable" buys you nothing — it is a tell that you have not thought through your buyer.

Anchoring. The first price the customer sees on the page sets the reference frame for every subsequent price. If your top tier is $1,000 and your default tier is $99, the $99 looks reasonable. If your top tier is missing and the customer encounters $99 cold, the $99 looks expensive. Lead with the highest credible price. Even if you do not expect customers to buy it, the anchor pulls the conversion rate of the lower tiers up.

Decoy effect. The decoy works only when the decoy is dominated — the customer can see, at a glance, that one option is strictly worse than another. The Economist's print-only-vs-print-and-digital-same-price is the textbook example. Most SaaS pricing decoys are not dominated; they are merely bigger or smaller, which produces a comparison, not a decoy. If you want a decoy, build one that no rational customer would pick.

How Sailop rotates pricing layouts

This is the practical reason this article exists. Sailop generates frontend design systems where every output is structurally distinct from every other output. The pricing page module is one of the components that rotates.

When you ask Sailop to generate a pricing page for a SaaS, the system does not default to three cards. It picks from a pool of fifteen-plus skeletons (the ones in this article, plus variants), weighted by inputs you provide: product type, buyer profile, audience size, regulatory context, indie-vs-enterprise framing. The same prompt, run twice with different seeds, produces structurally different pricing layouts.

This is the inverse of what AI generators do today. v0, Lovable, and Bolt converge toward the three-card lineup because their training data is dominated by it and their reward signals push them toward the conventional. Sailop diverges by design, because the question is not "what is the most popular pricing layout in the training data" — the answer to that is the three-card lineup, and we have established that the three-card lineup is wrong for most products. The question is "what is the right pricing layout for this product," and the answer requires structural variety.

If you want the underlying philosophy, the anti-slop prompt template sets out the rules. The 73-pattern decomposition in from AI slop to signature covers the visual side. This article covers pricing specifically because pricing is where the conversion math lives, and where structural sameness is most expensive.

The default is the three-card lineup. The default is wrong, most of the time. There are fifteen alternatives. Pick one. Or generate one with Sailop and skip the picking.

Closing

If you take one thing from this article, take this: your pricing page is not a feature comparison, it is a commitment moment. The job of the page is to remove the customer's last objection before they hand you their card. The three-card lineup does not do that job for most products. It does the job of a generic product, and most products are not generic.

Pick the layout that maps to the customer's actual decision tree. If the decision is "yes or no," use single-tier or free vs paid. If the decision is "how much," use a slider or calculator. If the decision is "which identity," use tier-as-paragraph or roles-based. If the decision is "is this for me at all," use FAQ-first or manifesto. If the decision is "how much will it cost in my exact configuration," use conditional or quote-on-request.

Do not pick the layout because your generator produced it. Pick it because it is correct.

And if you want to see what a pricing page looks like when it has not been touched by the AI-slop default — generate one with a tool that rotates structures by design, not by accident. Sailop is one. There will be others. The era of "every SaaS pricing page looks the same" should end. It does not end with better defaults. It ends with better defaults plus the willingness to ignore them.

Now go fix yours.