Turn Your Pricing Description Into a Working Catalog with AI
Describe your plans, limits, and usage rules; review the result; then let Tirdad create the features, meters, prices, entitlements, and usage units behind them.
Updated 2026-08-14
You know what you want to sell: a free plan, Growth at SAR 299 a month, 100 AI reports included, and SAR 0.50 for every report after the limit.
The hard part is turning that sentence into a catalog where every plan, meter, limit, and price agrees. Tirdad's AI pricing setup converts a plain-language description into that working structure. It does not decide your strategy for you. It builds the model you describe, shows it for review, and creates it only after you approve it.
Start with your model—not an empty configuration form.
Describe your pricing
Write the plans, prices, limits, and usage rules you already have in mind.
Choose a template
Start from Railway, Cursor, Gemini, Apollo, or Vapi when the pattern is already familiar.
Write the commercial promise first
AI can structure a clear decision. It cannot rescue a vague one. Before opening the setup, write down five facts:
| Decision | Example |
|---|---|
| What the customer buys | Completed AI reports |
| How plans differ | Free, Growth, and Scale |
| Recurring price | Growth at SAR 299 monthly |
| Included amount | 100 reports each billing cycle |
| What happens after the limit | SAR 0.50 per additional report |
Then describe the model in one compact prompt:
Create Free, Growth, and Scale plans for an AI reporting product. Growth costs SAR 299 monthly and includes 100 completed reports. Additional reports cost SAR 0.50 each. Scale costs SAR 799 monthly, includes 500 reports, and charges SAR 0.35 per additional report.
Name the customer action, not the supplier input. “Completed report” gives the catalog a usable meter. “Tokens, OCR pages, and model calls” exposes your cost stack without explaining what the customer receives.
Use a template when the pattern already exists
Tirdad includes templates for Railway, Cursor, Gemini, Apollo, and Vapi. Each represents a different billing pattern:
- infrastructure units and a prepaid pool;
- subscription plus usage overage;
- packaged token pricing with model filters;
- action-based usage units;
- or pure pay-as-you-go pricing.
A template is not a suggestion from AI. It is a known schema that opens directly in the preview. Choose one when its structure matches your product, then treat its names and numbers as an example—not as market evidence for your price.
Know what the description becomes
The preview may look like a set of plan cards, but Tirdad is building a deeper model behind them.
One description becomes the objects billing actually needs.
FEATURES + METERS
What customers use and how usage is counted
PLANS
How the offer is packaged
PRICES
Fixed fees and usage charges
ENTITLEMENTS
Included limits and access rules
USAGE UNITS
Recurring or one-time units attached to a plan
For a metered feature, the model can include the event name and whether each event counts as one unit or contributes a numeric amount. A voice product may sum minutes; an API product may count each request.completed event.
Plans can combine a recurring fee, usage charges, included limits, and plan-funded usage units. The combination matters. A monthly price without a meter cannot bill usage. A meter without a price records activity but does not create revenue. A limit without a clear customer action is difficult to enforce and harder to explain.
Review the preview as a contract
The preview is the decision boundary. Nothing has been added to the catalog yet. Use Back to change the description; use Create only when the model matches the promise you intend to publish.
Nothing is created until you approve the preview.
DESCRIPTION
Change the wording and assumptions
PREVIEW
Inspect the plans as customers will understand them
CREATE
Write the approved model into Tirdad
Review each plan across these questions:
| Check | What to verify |
|---|---|
| Plan | Name, audience, and billing period |
| Price | Currency, recurring amount, and one-time fees |
| Usage | The unit customers recognize |
| Included limit | The exact amount and reset period |
| Overage | The first unit after the limit and its price |
| Usage units | Amount, cadence, and conversion rule |
Do not approve the preview because the three cards look balanced. A wrong unit can produce a correct-looking card and a wrong invoice.
Approve creation once
After approval, Tirdad creates the catalog in dependency order. Features and meters come first. Plans and prices follow. Entitlements and usage-unit grants are added only when the model needs them.
From one description to a working catalog.
The setup checks for matching features and plans before creating them, which makes recovery safer if part of the process fails. Still, treat Create as a real catalog change—not a disposable mockup.
When setup finishes, open the product catalog and inspect the created objects. Confirm the event names your application must send, the lookup keys your integration will store, and the plan rules your product will enforce.
Test the catalog with one customer journey
Use a single scenario before announcing the pricing:
- Noura subscribes to Growth.
- Her first 100 completed reports stay inside the included amount.
- Report 101 records one additional unit.
- The usage charge uses SAR 0.50.
- The invoice explains both the recurring plan and the additional report.
That test connects the attractive plan card to the commercial result. If any step is ambiguous, go back to the feature, meter, price, or entitlement that owns the decision.
Describe the pricing you have decided, review the model Tirdad builds, and create it only when every customer-facing promise has one matching rule in the catalog.