Pricing Page Design skill for Claude Code

A pricing page is done when a target buyer can answer “which plan is mine, what will I actually pay, and what happens if I outgrow it or want to leave” without scrolling past the comparison table or contacting anyone — and every number on the page comes from the same source as the checkout.

Scope

This skill owns layout, comparison, interaction and trust on the page. Deciding prices, tiers and the value metric is pricing-strategy; headline and FAQ copywriting is landing-page-copy; testing variants is conversion-optimization; checkout and subscriptions are stripe-payments or merchant-of-record-billing.

Ground rules

• Prices come from one config (or the billing provider’s price IDs) shared with checkout. Hard-coded numbers in JSX drift from what customers are charged.
• Show the price. “Contact us” is acceptable only for the top enterprise tier, and even there “from $X/month” converts more serious leads than nothing.
• What a buyer will pay must be computable: unit, billing period, tax treatment, minimums and overage are visible, not in a footnote.
• No dark patterns: no fake strike-through “was” prices, no countdown timers that reset, no pre-selected add-ons, no hiding the monthly option. Regulators in the US, UK and EU actively pursue drip pricing and hard-to-cancel subscriptions.

The generic pricing page, and what to do instead

Template default	Do instead
Starter / Pro / Enterprise with no meaning	Name by audience or job: “Solo”, “Team”, “Company”; one-line “For…” under each name
Three identical cards, middle one scaled 105% with a gradient ribbon	One recommended plan marked with a reason (“Most teams of 5–50 choose this”), shown via border and label, not scale tricks
20 checkmark bullets per card	4–6 differentiators per card (what this plan adds), full list in the comparison table
Purple gradient background, glowing “Most popular” badge	Quiet neutral surface; the brand accent only on the recommended CTA
“Get started” on every card	CTA names the next step: “Start 14-day trial”, “Start free”, “Talk to sales”
Generic logo wall	Proof matched to the tier: a quote from a team-sized customer near Team, security badges and a named enterprise customer near Enterprise

Workflow

- [ ] 1. Gather plan data: tiers, value metric, limits, trial/free, currencies, tax
- [ ] 2. Identify the 3–5 buyer questions and objections (from sales and support)
- [ ] 3. Choose layout: cards only, cards + table, or calculator-led
- [ ] 4. Build plan cards and the billing toggle
- [ ] 5. Build the comparison table (desktop and mobile versions)
- [ ] 6. Add enterprise path, FAQ, and risk reducers at the decision points
- [ ] 7. Wire prices from config, add events, verify a11y and mobile

1–2. Inputs

Get from the user or pricing-strategy output: tier names, prices per currency, billing periods, the value metric (seats, usage, projects), limits per tier, trial length and whether a card is required, and tax display (B2C in the EU/UK typically shows VAT-inclusive prices; B2B usually shows excl. tax with a note). From sales/support: the questions buyers actually ask (“Can I add one seat?”, “What happens at the limit?”, “Do you offer annual invoicing?”).

3. Layout choice

Pricing model	Layout
2–4 flat tiers	Plan cards + comparison table below
Per-seat	Cards showing per-seat price + seat selector that updates totals
Usage-based	Calculator-led: slider or inputs with presets (“Small”, “Growing”), example bills, then plans
Free + one paid	Two-column comparison, no table needed
Enterprise-only	Short page: what’s included, process, “from” price, contact form

Never show more than 4 plan cards side by side; additional tiers (non-profit, education, startups) go in a band below.

4. Plan cards and toggle

Card anatomy, top to bottom: plan name, “For …” line, price (large) with unit and period directly attached (“$12 per seat / month”), billing clarifier (“billed annually, $144”), primary CTA, “Everything in Solo, plus:” then 4–6 differentiators, then the key limit.

Billing toggle rules:

• Default to the period most customers buy. If annual is default, monthly-equivalent price must state “billed annually” and the annual total.
• Express savings as a concrete amount or months (“2 months free”, “save $48/year”), and make sure it is arithmetically true for every plan.
• Implement as a radio group (two options), not a checkbox switch whose state is unclear:

<fieldset class="billing-toggle">
  <legend class="visually-hidden">Billing period</legend>
  <label><input type="radio" name="period" value="monthly"> Monthly</label>
  <label><input type="radio" name="period" value="annual" checked> Annual <span>2 months free</span></label>
</fieldset>

• Update prices with aria-live="polite" on the price region so screen readers hear the change; avoid animating numbers on every toggle.
• Prices use tabular figures (font-variant-numeric: tabular-nums) and align across cards; the currency symbol and period are smaller than the number.

5. Comparison table

• Real <table> with <th scope="col"> plan headers and <th scope="row"> feature names; group rows under section headers (Collaboration, Security, Support).
• Sticky header row with plan names, prices and CTAs while scrolling.
• Cells contain values, not just checks: “10 GB”, “3 projects”, “Unlimited”, ”—”. Checkmark icons need text alternatives (“Included” / “Not included”).
• Jargon gets a one-line explanation in an accessible tooltip or a footnote link.
• Put the rows that drive upgrades (limits, SSO, audit logs, support SLA) first in each group; cut rows that are identical across all plans into a single “All plans include” list above the table.
• Mobile: do not shrink a 4-column table. Use a plan switcher (segmented control or select) that shows one plan’s column next to feature names, or a two-plan compare with selectable columns. Recommended plan shown first.

6. Enterprise, FAQ, risk reducers

• Enterprise: list what is actually different (SSO/SCIM, audit logs, DPA, uptime SLA, invoicing, dedicated support), give “from” pricing when possible, and offer two paths: “Talk to sales” (short form: name, work email, team size) and “Start a trial of Team” for evaluators not ready to talk.
• FAQ: 5–8 billing questions, answered specifically: changing plans and proration, what happens at the limit (hard stop vs overage price), cancellation and refunds, payment methods and invoicing, discounts (annual, non-profit, education), data retention after cancel, taxes. Use <details>/<summary> or headings, not a JS-only accordion.
• Risk reducers next to the CTA they support: “No card required” under the trial button, “Cancel anytime” and refund policy near paid CTAs, SOC 2 / GDPR / SSO badges near Enterprise.
• Currency: show local currency via geolocation with a visible switcher; never convert on the fly with live FX if checkout charges a fixed price list.

7. Implementation and verification

Single source of truth example:

// pricing.config.ts — also imported by checkout
export const plans = [
  { id: "team", name: "Team", for: "For teams of 2–50",
    price: { monthly: 15, annual: 12 }, unit: "seat", currency: "USD",
    stripePriceId: { monthly: "price_team_m", annual: "price_team_y" },
    limits: { projects: "Unlimited", storageGb: 100 }, recommended: true },
] as const;

• Add a test that asserts every displayed price matches the billing provider’s price object (amount, currency, interval) — run it in CI.
• Events: pricing_viewed, billing_period_changed {period}, plan_cta_clicked {plan, period}, pricing_faq_opened {question}; FAQ opens reveal objections worth moving onto the page.

Verify:

1. Five-second test with a target-buyer description: they can name their plan and its monthly cost.
2. Every price and saving claim checked against checkout for each currency and period.
3. Keyboard: toggle, plan switcher, tooltips and FAQ all operable; prices announced on change; table headers read correctly in a screen reader.
4. 320px width: no horizontal scroll except an intentional plan switcher; CTAs visible without scrolling past long feature lists.
5. Lighthouse/axe: no contrast failures on muted “billed annually” text (keep at least 4.5:1).

Gotchas

• Showing the annual monthly-equivalent price as if it were the monthly price.
• A “recommended” badge on the plan the company wants to sell rather than the one most of the target audience fits; buyers notice when the features do not justify it.
• Limits described with internal units (“credits”, “compute units”) without an example of what a unit buys.
• Feature lists that differ between card bullets and the table.
• Removing the free plan link from the page while the plan still exists, which pushes support tickets up and trust down.
• Enterprise forms with 12 required fields; ask for 3–4 and qualify later.

Output when reporting

**Layout:** 3 cards (Solo, Team [recommended], Company) + enterprise band + comparison table (5 groups, 22 rows)
**Toggle:** annual default, "2 months free", radio group with aria-live price region
**Prices:** from pricing.config.ts; CI test matches Stripe prices for USD/EUR/GBP
**Mobile:** plan switcher for table; recommended plan first
**FAQ:** 7 billing questions; risk reducers at each CTA
**Verified:** 5-second test 4/5 correct plan; axe 0 violations; 320px no overflow