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/skills 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 the user wants to run the project's lint + types + build sequence as a gate before pushing, opening a PR, or merging. Invoked by chained dev skills between phases. Trigger phrases - "/quality-gate", "run the quality gate", "check it builds".
tools
Use when the user wants to verify a PR's feature works at runtime by booting the dev server, exercising the affected UI via Chrome DevTools MCP, and posting a screenshot summary back to the PR. Idempotent — skips if `verified` or `verify-failed` is already on the PR. Trigger phrases - "/pr-verify", "verify this PR", "runtime check the pr".
testing
Use when the user wants a security-focused review pass on a PR with findings actioned as commits on the same branch. Trigger phrases - "/pr-security-review", "security review and fix".
testing
Use when the user wants to open a pull request for an already-pushed branch that implements a specific issue. Idempotent — returns the existing PR if one is already open for the branch. Trigger phrases - "/pr-open", "open the pr", "create pr for this branch".