A pricing page people trust

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# A pricing page people trust

Many launch visitors to the production site go straight to the pricing page. Confusing plans, prices that differ at checkout, or hidden limits lose them and generate angry comments. Make the pricing page clear, consistent with what checkout charges, and complete enough that nobody has to email to ask.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Change prices or plans in the billing provider.
- Invent discounts or guarantees.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Check pricing against billing

Find where plans and prices are defined in the code and in the billing provider's configuration. List every place a price appears (pricing page, checkout, emails, docs) and flag any mismatch. Prices should come from one source in code.

### 2. Plans people can compare

Two to four plans, each with a name, a price, who it is for in one line, and its limits in concrete numbers. Mark one as recommended if that is true. Show monthly and yearly prices clearly (with the yearly saving), the currency, and whether tax is included.

### 3. Answer the questions

Add an FAQ under the plans: is there a free plan or trial and what happens after it, can I cancel anytime, what payment methods, refunds, what happens if I exceed a limit, discounts for students or open source if they exist. Ask me for anything you cannot find in the code.

### 4. Make the next step obvious

Each plan's button says what happens ("Start free trial", "Buy yearly") and goes straight to sign-up or checkout with that plan selected. Add `Offer` data to structured data only with the real prices.

## Done means

- [ ] Every price shown matches what checkout charges, from one source in code.
- [ ] Each plan shows who it is for, its limits in numbers, and monthly and yearly prices with currency.
- [ ] An FAQ answers trials, cancelling, refunds, payment methods and limits.
- [ ] Each plan's button starts sign-up or checkout with that plan.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.