Pricing Page Builder
Publish a pricing page whose numbers come from the real plans, not a hand-edited table.
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
5
What your agent is told to do
5-
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
8
Edge cases it handles
8- 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
9
Definition of done
9- 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
Popup Builder
Popup Builder
Design an on-site popup and control who sees it, when it appears, and how often.
What it does
An authoring tool for on-site popups covering content, targeting rules, trigger conditions and frequency, plus the runtime that displays them.
How it works
- 1 Render popups through the app's existing dialog behaviour rather than a new overlay. If Accessible Modal and Drawer Behaviour or Focus Containment Primitive exists, the popup is built on it and inherits focus trapping, escape handling and scroll locking for free.
- 2 Keep the content model to a few block types the app can actually render: heading, body text, an image, a button, and an email capture field. A free-form layout editor inside a popup is a page builder in disguise and should be deferred.
- 3 Make targeting explicit and default to nobody. An author chooses audience, pages and trigger before the popup can be published, so an unfinished draft never reaches a customer.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/popup-builder
Survey Builder
Survey Builder
Build a multi-question survey, send it out, and read all the answers in one place.
What it does
An authoring tool for multi-question surveys, a respondent flow, and a results view with export.
How it works
- 1 Ship a small, honest set of question types first: single choice, multiple choice, short text, long text, and a rating scale. That covers most real surveys. Defer matrix grids, file uploads, and calculated fields rather than half-building them.
- 2 Render the respondent flow with the app's existing Multi-Step Form and Conditional Form Fields, and reuse Form Field Shell for the inputs, so a survey looks and behaves like every other form in the product.
- 3 Give surveys the app's existing Draft and Publish States. Editing a live survey while responses are arriving is the main way survey data gets corrupted, so publishing must be a deliberate act with a clear boundary.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/survey-builder
Video Trimmer
Video Trimmer
Let someone set a start and end point on an uploaded video and save the trimmed clip.
What it does
A trim step on uploaded video, with a scrubbable timeline, in and out handles, and server-side processing of the result.
How it works
- 1 Build the trim on top of the app's existing upload path. Size and type limits stay enforced server-side, and if Upload Malware Scanning exists the source file is scanned before any processing job is queued.
- 2 Keep the interface to what the customer needs: a preview, a scrubbable timeline with thumbnails, draggable in and out handles, and numeric time fields for precision. Multi-clip editing and transitions are a different product and should be deferred.
- 3 Do the trimming on the server as a background job and report its state through the app's existing job progress surface rather than a bespoke spinner.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/video-trimmer
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.