Most SaaS pricing was never designed — it evolved. A founder picked a number at launch, added a tier when a big customer asked, bolted on an add-on when costs appeared. Five years later nobody can explain why the price points are what they are, expansion revenue is flat, and every pricing conversation ends with “we should look at that someday.”
Pricing Architecture is that look — done properly, with your data, and validated before you bet the funnel on it.
What decision this drives
What to charge, and who pays for what. That decomposes into the decisions most companies never make explicitly: how many tiers and where the boundaries sit, which features gate which tier, what’s metered vs. unlimited, how usage-based costs (messaging, AI, transactions) get absorbed or passed through, and what the upgrade path actually looks like from the customer’s side.
What it looks like
The work runs in three passes:
- Revenue decomposition — current ARPU by segment, plan mix, expansion vs. new-logo split, unit costs for usage-driven features. Where the money actually comes from, not where the pricing page says it should.
- Architecture design — tier structure, price points, feature gating table (what’s free, what’s metered, what’s gated), add-on economics modelled against real unit costs.
- Validation design — how to test before full rollout: what sample sizes you actually need, what a clean read requires, and when a test is statistical noise dressed up as a verdict. Pricing tests need different infrastructure than feature tests; most companies run them the same way and get garbage.
What you get
- Tier structure and price points with the reasoning documented — defensible to your board, not just “competitor X charges this”
- Feature gating table: per-feature decisions on free / metered / gated, with the upgrade levers identified
- Usage-cost model for any metered features (messaging, AI, transactions) — absorption formula or pass-through pricing
- Rollout plan: validation approach, migration path for existing customers, contingencies
- Revenue impact model at current churn levels
Real result
At a hospitality SaaS (~€3M ARR), a tiered pricing redesign was validated by A/B test at +19% MRR per single-property customer — the volume drop it caused was more than offset by the revenue per customer. A follow-up price-elasticity test was correctly called as statistical noise rather than shipped on a false positive, and usage-based messaging pricing was designed as a margin-aware percentage-of-MRR allocation with add-on packages.
Price
€6,000 fixed, 5 weeks.