saas-pricing-strategy/SKILL.md
Use when making SaaS pricing decisions, structuring pricing tiers, choosing a value metric, planning a price increase, or designing a pricing page. Produces a pricing recommendation with tier structure, value metric rationale, and pricing page guidance.
npx skillsauth add paulund/ai saas-pricing-strategyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
references/pricing-guide.md for frameworks and templates.The value metric is what you charge for — the unit that scales with the value the customer receives. Choosing the wrong metric is the most common SaaS pricing mistake.
| Metric | Works well when | Examples | | --- | --- | --- | | Per seat / per user | Value scales with number of people using it | Slack, Figma, Notion | | Per usage | Value comes from consumption | Twilio (per message), AWS (per compute) | | Per contact / record | Value scales with the customer's audience size | Mailchimp (per subscriber), HubSpot (per contact) | | Per feature | Different tiers unlock qualitatively different functionality | Intercom, Canva | | Flat rate | Simple, but does not capture value from power users | Basecamp | | Per transaction | Value tied to customer revenue | Stripe (per transaction), Shopify (per sale) |
The test: As the customer gets more value from your product, does the metric you charge for increase proportionally? If yes, it is a good value metric.
Most SaaS products should have 3 tiers. More than 4 creates decision paralysis.
| Tier | Goal | Pricing psychology | | --- | --- | --- | | Entry / Free / Starter | Reduce barrier to entry, drive adoption | Lowest friction possible | | Recommended (highlight this) | Where most customers should land | Best value, most features | | Premium / Pro / Business | Capture high-value customers | Higher limits, advanced features, more support |
Differentiators between tiers:
The recommended tier: Make one tier visually distinct as "most popular" or "best value." Most customers will choose it. Price the entry tier low enough to be accessible, the recommended tier at 3-5x the entry, and the premium tier at 2-3x the recommended.
These are different strategies with different outcomes:
| Approach | When to use | Risk | | --- | --- | --- | | Free forever tier | When there is a large enough user base to convert, and free users create value (network effects, referrals, SEO) | Free users never convert | | Time-limited trial | When the product delivers clear value quickly and users need to see it | Trial ends before value is demonstrated | | Feature-limited free | When some features have viral/sharing properties | Free tier cannibalises paid | | No free tier | B2B with a sales motion, or when free users have meaningful infrastructure cost | Higher acquisition friction |
Put the most expensive tier first (left to right on a pricing page). This makes the middle tier feel reasonable by comparison.
A third tier that makes one of the others look like better value. The professional tier at $49/month looks good when the enterprise tier is $199/month.
17-20% annual discount is standard. "2 months free" framing performs better than "17% off" even though they are the same number.
| Topic | Reference | Load When |
| ----- | --------- | --------- |
| Pricing Frameworks | references/pricing-guide.md | Always |
development
Use when implementing any logic, fixing any bug, or changing any behaviour. Use when you need to prove code works, when a bug report arrives, or when modifying existing functionality. Do NOT use for config changes, data migrations, or dependency updates.
development
Use when starting a new feature, when requirements are unclear, when asked to write code without a clear spec, or before any non-trivial implementation. Do NOT use for trivial bug fixes or one-line changes.
development
Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. Detects the stack from dependency files, fetches official documentation, implements following documented patterns, and cites sources for every framework-specific decision.
development
Use when preparing to ship a feature, release, or deployment. Use before merging to main, creating a release, or deploying to production. Do NOT use for CI-only changes or internal refactors that don't reach production.