Pricing page teardown, run by an AI in minutes

This page is for anyone who owns a pricing page and wants to know what buyers actually take away from it. It is one of the ready-made studies in the use cases for visual product feedback hub, alongside AI usability testing.

What a pricing page teardown is

A pricing page teardown is a review of a pricing page from the buyer's side: can a specific person, arriving with a specific situation, work out what they would pay, which plan is theirs, and what happens next, without misreading anything.

It is not a pricing strategy review. It does not ask whether $12 should be $15, or whether three tiers beat four. Those are business decisions. The teardown asks a narrower, more testable question: given the prices you chose, does the page transmit them correctly? Pricing pages fail that test constantly and quietly, because the people who built them already know the answers.

The classic example: two tiers say "per month for one person," the third says "per month per person," and the third is the one with the Recommended badge. A solo buyer anchored on "$180 versus $250, only $70 more" never notices that the third tier multiplies by seat. Nothing on the page is false. The buyer still leaves with the wrong number.

How the AI runs it

You give it the pricing URL. It opens a review, then works through six passes, taking a screenshot of every state it judges and quoting the exact text at issue.

1. The five-second fold. From the first screen alone, on desktop and then on a phone: how many plans, which one is for someone like me, and what does it cost, with the unit. If any answer needed a scroll, a toggle, or a calculation, that is the first finding.
2. The buyer math. Three concrete buyers, a solo user, a team of five, and a company of twenty-five. For each, the total per month and per year on the tier the page steers them to, showing the arithmetic. Every place the number was hard to reach is a finding: per-seat wording that switches between tiers, annual totals where the buyer thinks in months, multipliers the buyer has to compute, add-ons that only appear after choosing a plan, a currency never stated. "Cannot determine" is the most important finding on a pricing page.
3. Tier architecture. Do the tier names and taglines tell a buyer which one is theirs, and do the price model and features agree with that label? Which tier is pushed, and does its economics fit the buyer the page most likely receives? What specifically forces the jump from each tier to the next? Is the enterprise gate specific or a fog? Is there a trial, how long, is a card required, and what happens when it ends?
4. The feature table and the fine print. Can a buyer tell a limit from a feature at a glance? Are load-bearing terms like seat, workspace, or credit defined? Are usage-based components disclosed here rather than at checkout? Does any footnote or FAQ answer contradict the cards above it?
5. Trust at the ask. What reassures the buyer near each button, and what works against trust: a price that differs from the homepage, a "most popular" badge on the most expensive tier, fake scarcity, a footer with the wrong year.
6. Phone. Tiers stack in a different order on a small screen, the highlighted tier can fall below the fold, and feature tables collapse. The teardown re-judges the first and third passes at phone width.

At the end it writes the verdict at the top of the review: the price story the page actually transmits in one sentence, the buyer math table, findings ordered by severity, and a keep-list of what works.

What comes back

A review at a shareable link. The verdict sits at the top, the screenshots and notes below it in the order they were taken. Findings use three severities:

• Misleads. A buyer would misjudge what it costs or which tier is theirs. Pricing-model switches between tiers, hidden add-ons, footnotes that change the price.
• Stalls. A buyer cannot decide without contacting someone or doing math the page should have done. Undefined units, vague tier differences, missing trial terms.
• Friction. Minor. A toggle default, a table that collapses badly on a phone.

Severity is anchored on outcome. A finding has to plausibly change what a buyer believes they would pay, which tier they pick, or whether they can decide at all.

The review exports as markdown a coding agent can act on, as a PDF for a teammate, or as a GitHub issue. Run it again after the page changes and the next review leads with what got fixed and what is still open.

Running it

From Claude chat, with no code. Add Cobalt Capture as a connector once, then ask:

Run a pricing teardown of https://example.com/pricing

The assistant has no browser, so Cobalt renders the page for it, on desktop and on a phone. One limit: from chat it cannot flip the page's own monthly and annual toggle, so it judges the default state and says which state that was. That default is what most visitors see anyway.

From a coding agent. In Claude Code, /mcp__cobalt__pricing_teardown https://example.com/pricing. The agent drives a real browser, so it captures every toggle state as well. The studies page has the paste-ready block for Cursor and Codex.

When to run it

• Before a pricing change ships, on the staging version, so the new page is checked the way buyers will read it rather than the way the team that built it does.
• After any change to tiers, limits, or add-ons. The page is usually edited in pieces, and the footnote that no longer matches the card is the kind of thing nobody notices from inside.
• On competitors. It reads public pages only, so three competitor pages plus your own is a fast read on what the category's buyers are used to.
• Periodically, as a regression check. A saved review is a baseline; the next run reports the delta.

Frequently asked questions

What is a pricing page teardown?

A pricing page teardown is a structured review of a pricing page from the buyer's side: can a specific person, arriving with a specific situation, work out what they would pay, which plan is theirs, and what happens next, without misreading anything. It is different from a pricing strategy review. It does not ask whether the prices are right; it asks whether the page communicates them correctly.

What does the teardown actually check?

Six passes. A five-second test of what the page says above the fold on desktop and phone. The buyer math: the total a solo user, a team of five, and a company of twenty-five would pay per month and per year, and every place that number was hard to reach. Tier architecture: whether each plan's name matches its price model and features, which tier is pushed, what forces an upgrade, and whether the enterprise gate is specific. The feature table and fine print, including footnotes that contradict the cards. Trust near the call to action. And a phone pass, because tiers stack in a different order on a small screen.

Do I need a developer or any setup?

No. Add Cobalt Capture as a connector in Claude chat once, then ask for a pricing teardown of your URL in plain words. The assistant has no browser of its own, so Cobalt takes the screenshots for it, on desktop and phone. If you use a coding agent such as Claude Code or Cursor, the same study runs there with the agent driving a real browser, which also lets it flip the monthly and annual toggles.

What do I get back?

A review at a shareable link, with the verdict at the top: the price story your page actually transmits in one sentence, the buyer math table, findings ordered by severity (misleads a buyer, stalls a buyer, minor friction), and a keep-list of what the page does well so nobody regresses it. Every finding has a screenshot and quotes the exact text at issue. You can export it as markdown for a coding agent, a PDF for a teammate, or push it to GitHub as an issue.

Can I run it on a competitor's pricing page?

Yes. It reads public pages only, never starts a checkout or creates an account, so running it on any public pricing page is fine. Running it on three competitors and your own page is a fast way to see what buyers experience across the category.

How is severity decided?

On outcome, not taste. A finding has to plausibly change what a buyer believes they would pay, which tier they pick, or whether they can decide at all. A recommended tier that is the only one priced per seat, with the page never saying so above the fold, is a finding. A layout the reviewer would have done differently is not.