TL;DR
Don’t ask AI “what should I charge?” — it has no access to your margins or conversion data, so it guesses. Instead, use it to generate 3 distinct pricing shapes (not three numbers), pressure-test each against a segment, and hand you a one-week experiment per shape. The shape decision (per-seat vs. usage vs. hybrid vs. outcome) matters more than the dollar figure: as of June 2026, pure per-seat pricing has fallen to about 15% of SaaS companies while hybrid base-plus-usage models are on track to hit roughly 61% by year-end. This guide gives you exactly what to feed the model, a copy-ready prompt, and how to validate the output before a single price goes live.
The task
You’re pre-launch, or you’re considering a price change, and pricing is unclear. There are a dozen plausible plans: free + paid, freemium + premium, per-seat, usage-based, value-based packaging, outcome-based. The wrong shape costs you far more than the wrong number. The goal here isn’t to guess a price — it’s to produce 3 distinct hypotheses, each with a validation experiment you can run in a week.
This workflow is for SaaS founders before the pricing page goes live, indie devs deciding between subscription and one-time, and product teams introducing a new tier.
The 2026 pricing-shape landscape (use this to constrain the AI)
Pricing “shape” is the structural decision the model should reason about first. Here’s where the market sits as of June 2026, so neither you nor the AI anchors on an outdated default like “everyone charges per seat.”
| Shape | What you bill for | 2026 status | Best fit |
|---|---|---|---|
| Per-seat | Each named user | Declining — roughly 21% → 15% of SaaS in ~12 months | Collaboration tools with clear per-user value |
| Usage-based | Consumed units (API calls, GB, runs) | ~77% of the largest software firms now include a consumption component | Products with variable cost-of-goods per customer (esp. AI) |
| Hybrid (base + usage) | Flat floor plus variable overage | The winner — ~43% of SaaS today, projected ~61% by end of 2026 | Most modern SaaS wanting both predictability and upside |
| Outcome-based | Successful results only | Emerging frontier; e.g. AI-support vendors bill per resolved ticket | AI agents where “value delivered” is measurable |
Two reasons this matters for your prompt: (1) AI models trained on older data tend to default to per-seat, which is now the shrinking option; (2) if your cost-of-goods varies wildly per customer (anything with heavy LLM inference), flat pricing quietly loses money on power users, so the model should at least surface a usage or hybrid hypothesis.
When AI is the right tool
Use AI for the structuring step: given your product, audience, and willingness-to-pay signals, a capable model (GPT-5.5, Claude Opus 4.7, or Gemini 3.1 Pro as of June 2026) can generate distinct pricing shapes and reason about which segment each shape serves best. With 1M-token context on Opus 4.7, Sonnet 4.6, and Gemini 3.1 Pro, you can paste full competitor pricing pages and raw customer-interview transcripts and let the model find the packaging boundaries.
It’s also good for stress-testing: paste your current hypothesis and ask “what’s the single most likely failure mode, and what early signal would reveal it in week one?”
When not to rely on AI alone
AI doesn’t know your real conversion data, your support cost per customer, or your gross-margin reality. The pricing math has to be done by you with actual numbers, not by the model with assumptions. Always validate each suggested price against your gross-margin floor by hand.
Skip pure-AI pricing for regulated industries where prices must comply with specific rules (insurance, healthcare, lending).
What to feed the AI
- Product: what it does, and the core unit of value (a project, a seat, an API call, a resolved ticket, a saved hour)
- Audience: the specific segment + buying motion (self-serve vs. sales-led)
- WTP signals: what 5–10 target customers said they’d pay, in their own words — ideally collected with a structured method like the Van Westendorp Price Sensitivity Meter (its four questions converge on an acceptable price band)
- Competitor pricing: 3–5 closest competitors, with the shape noted, not just the price
- Constraints: gross-margin floor, billing system (Stripe at ~2.9% + 30¢ domestic vs. Paddle as merchant-of-record at ~5% + 50¢ changes your floor), geographic targeting
- One thing you’re certain about and one thing you’re unsure about
Those last two certainty/uncertainty items keep the model from defaulting to lazy, generic answers.
Copy-ready prompt
Replace each [bracketed] placeholder with your real inputs, then paste into your model of choice.
You are a pricing strategist. Generate 3 DISTINCT pricing hypotheses for the
product below. Each must use a different pricing SHAPE (e.g. per-seat,
usage-based, hybrid base+usage, outcome-based) — not three versions of the
same shape with different numbers.
Product: [what it does + core value unit]
Audience: [segment + buying motion: self-serve or sales-led]
WTP signals: [5-10 customer quotes with numbers]
Competitor pricing (with shape): [comp list]
Constraints: [margin floor], [billing system], [geo / currency]
Certain: [the one thing I'm sure of]
Unsure: [the one thing I'm unsure of]
For each of the 3 hypotheses, output:
- One-line summary of the pricing shape
- Plan structure: tiers, what's in each, anchor price + currency
- Target segment + the JTBD this shape serves
- Why this shape (one paragraph; be contrarian if it fits)
- Key risk: what would make this fail
- Leading indicators to monitor in week 1
- A 1-week validation experiment (specific: who, how, what to measure)
Keep one of the three deliberately contrarian.
End with "which to test first and why," and for each hypothesis add a
one-line "what we'd learn even if it fails."How to validate the output before you commit
Model output is a starting hypothesis, never a decision. Run each suggestion through this checklist:
- Margin check — validate every price against your gross-margin floor by hand, including payment-processor fees. A price that clears Stripe’s ~2.9% + 30¢ may not clear Paddle’s ~5% + 50¢.
- Reachability check — confirm each hypothesis maps to a segment you can actually reach this month. Don’t accept “enterprise CIOs” if you have no enterprise sales motion.
- One-week test — each validation experiment must be runnable in a week with no engineering. A “painted-door” pricing page (the price is live; clicking it joins a waitlist instead of charging) is the fastest no-code option.
- Real conversations — run all three hypotheses past 10 target customers in actual conversations. Conversation data beats any model output.
Always keep one of the three hypotheses contrarian — often the one nobody on the team likes. That’s frequently where the biggest signal lives. The bar for a worthwhile experiment is the “what we’d learn even if it fails” line: if you can’t fill it in, the test isn’t designed yet.
Don’t forget price localization
If you sell internationally, a single USD price leaves conversion on the table. Displaying prices in the local currency lifts conversion by roughly 25% on average, and purchasing-power-parity (PPP) pricing — a $50 US plan priced nearer $14 in India, for example — has been associated with materially higher conversion in lower-income markets. Make “should one hypothesis include localized/PPP tiers?” an explicit question for the model if your audience is global. Stripe and Paddle both support geographic and multi-currency pricing natively, so this is a config decision, not an engineering one.
Common mistakes
- Treating pricing as one number — shape matters more than dollars
- No validation experiment, just “guess and watch the dashboard”
- Defaulting to per-seat because the model suggested it (it’s the shrinking model in 2026)
- Cargo-culted competitor pricing that ignores your unit cost and processor fees
- A free tier so generous nobody upgrades, or so stingy nobody signs up
- Skipping the contrarian hypothesis (the one that surprises you)
Next steps to keep improving
After your first 30 days of pricing live, paste your actual data back into the model along with what you learned, and ask for “the next 3 hypotheses to test.” Pricing is a series of tests, not a one-time decision. Lock a hypothesis in only when the same one wins across two segments over about 60 days — then revisit it annually.
FAQ
How many pricing hypotheses should I run live at once? Two at most. More than two splits your traffic and muddies the signal. Generate three with AI, then pick the two strongest (keep one contrarian) to actually test.
Which AI model is best for this? Any frontier model handles the reasoning well as of June 2026. GPT-5.5, Claude Opus 4.7, and Gemini 3.1 Pro all have 1M-token context, so the practical edge is pasting your full competitor pages and interview transcripts rather than summaries. Use the same prompt across two models and compare where they disagree — the disagreements flag your riskiest assumptions.
How do I collect real willingness-to-pay numbers to feed in? A structured Van Westendorp survey (four questions: too cheap, bargain, getting expensive, too expensive) converges on an acceptable price band. Aim for 100+ responses per segment for statistical confidence; for early validation, 10 real conversations beat a thin survey.
Should discounts be part of a hypothesis? No — don’t bake discounts into the base price. Test the base price first, then run discounting as a separate experiment so you can read each signal cleanly.
When do I lock pricing in? When the same hypothesis wins across two distinct segments over roughly 60 days. Then treat it as settled and revisit annually, or sooner if your cost-of-goods shifts (common with AI-heavy products).
Related
Reuse the structure with pricing hypothesis prompts, align pricing to your message with product positioning prompts, and pressure-test the underlying idea using startup idea evaluation prompts. For authoritative pricing-model context, see Bessemer’s AI pricing and monetization playbook and Paddle’s guide to SaaS pricing models.