Pricing Page Builder

Publish a pricing page whose numbers come from the real plans, not a hand-edited table.

moderate Editors & Builders

What it adds

An editable public pricing page whose tiers, prices, and feature rows are driven by the app's actual plan records.

What your agent is told to do

1
Read prices and plan names from the billing system rather than from copy typed into the page. The page should be laid out by hand and priced by the system.
2
If the app already has a plan comparison surface for signed-in users, extend it so both the public page and the in-app upgrade screen render from one set of plan and feature records.
3
Give each plan an explicit public flag. Default it to hidden so legacy, custom, and internal plans never appear on the page just because someone created them.
4
Build the feature comparison from a shared list of feature rows with a value per plan, so every tier has the same rows in the same order even when the value is simply absent.
5
Do not cache the published page indefinitely. A price change in billing must invalidate the page, because a stale price on a public page is a commitment you may have to honour.

Edge cases it handles

A price changed in the billing system while the published page still shows the old number is the worst failure here. Invalidate the page on plan change and show authors when the page last rebuilt.
Currency and tax display differ by visitor region. Decide whether prices are shown inclusive or exclusive of tax, say which on the page, and do not guess a currency the plan is not actually sold in.
A monthly and annual toggle must compute the annual figure from the real annual price, not by multiplying the monthly one. Show both the per-month equivalent and the amount actually charged, and round them consistently.
Legacy and hidden plans must never appear publicly even when an existing customer is still on one, and the page must not imply that customer's plan no longer exists.
Feature comparison rows misalign as soon as one tier has more features than another. Render every row for every tier and mark absence explicitly rather than collapsing the row.
A signed-in visitor should see their current plan marked as current, and the call to action should read as a change of plan rather than a fresh signup.
Prices with a promotional or introductory rate need the standard rate visible too, or the page will be read as the ongoing price.
The page must render sensibly when a plan has no price yet, such as an enterprise tier, without printing a zero.

Definition of done

Tier names and prices are read from the billing records rather than stored as page copy.
A price change in billing is reflected on the published page without a manual edit.
Only plans explicitly flagged public appear, and hidden or legacy plans never render.
Every comparison row is present for every tier, with absence marked rather than omitted.
The billing period toggle shows both the charged amount and the per-month equivalent.
Currency and tax treatment are stated on the page.
A signed-in visitor sees their current plan identified.
The feature matches the existing design system.
No existing functionality is broken.

Related features

Survey Builder

Automation Builder

Quiz Builder

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.