At what stage should I actually start building grandfathering logic, not just designing for it?

Roughly, the moment you have paying customers and you're considering any change to pricing or plan structure, even a small one. You don't need a full system before that. You do need your data model to already support it, which is why the products/prices split belongs earlier than the grandfathering logic itself.

Isn't A/B testing pricing too risky for a small SaaS anyway?

The perceived risk is usually higher than the actual risk, which is part of why only a small share of SaaS companies test pricing regularly despite the growth data favoring those that do. The real constraint at small scale isn't risk, it's volume, you often don't have enough traffic for a test to mean anything statistically.

Do I need multi-currency support before I have an international customer asking for it?

No. This is one of the clearer cases where building ahead of demand is wasted work. What you want ahead of demand is a price model where adding a currency variant is additive rather than a schema change under deadline pressure.

Is this just an argument for using Stripe's data model as my own?

Not exactly. It's an argument that whatever your internal model is, it shouldn't be more mutable than the vendor you're likely to build on assumes it should be. Stripe not allowing price mutation is a signal worth listening to independent of whether you use Stripe.

How does this connect to feature flags and access control?

A scopes or capability-based access model is what lets feature deprecation and feature-level packaging happen without touching plan names directly. It's the same underlying idea as the pricing split: separate the stable concept (what a customer can do) from the thing that changes over time (what plan or price that's currently attached to).

The Pricing Capabilities You'll Need Before You Think You Need Them

A staged framework for knowing which pricing capabilities matter at each phase of a SaaS, and what breaks the day you need one you didn't build.

Yoann Jaspar

August 13, 2026 9 min read The Production SaaS Playbook

Pricing infrastructure costs almost nothing to design correctly pre-revenue and a lot to retrofit once customers exist. The highest-leverage early decision is splitting product identity from price identity in your data model.
Grandfathering, feature deprecation, and plan migration aren't scale-stage problems. They show up the moment you have your first cohort of paying customers, and most of the damage comes from having no concept for them at all, not from an imperfect implementation.
A/B price testing and multi-currency support only start paying for themselves at real volume. Building them early is usually wasted effort, but the underlying price model needs to already support variants for either to be additive rather than a rewrite.
Feature-level packaging via scopes or capability flags matters most once your fixed tiers stop matching how real customers want to buy, which tends to surface at scale, not before.
The same adapter discipline you'd apply to a mailer or deployment provider applies to your payment processor. Stripe today doesn't have to mean Stripe forever, provided the billing domain logic isn't written directly against Stripe's API shape.

FAQ

At what stage should I actually start building grandfathering logic, not just designing for it?: Roughly, the moment you have paying customers and you're considering any change to pricing or plan structure, even a small one. You don't need a full system before that. You do need your data model to already support it, which is why the products/prices split belongs earlier than the grandfathering logic itself.
Isn't A/B testing pricing too risky for a small SaaS anyway?: The perceived risk is usually higher than the actual risk, which is part of why only a small share of SaaS companies test pricing regularly despite the growth data favoring those that do. The real constraint at small scale isn't risk, it's volume, you often don't have enough traffic for a test to mean anything statistically.
Do I need multi-currency support before I have an international customer asking for it?: No. This is one of the clearer cases where building ahead of demand is wasted work. What you want ahead of demand is a price model where adding a currency variant is additive rather than a schema change under deadline pressure.
Is this just an argument for using Stripe's data model as my own?: Not exactly. It's an argument that whatever your internal model is, it shouldn't be more mutable than the vendor you're likely to build on assumes it should be. Stripe not allowing price mutation is a signal worth listening to independent of whether you use Stripe.
How does this connect to feature flags and access control?: A scopes or capability-based access model is what lets feature deprecation and feature-level packaging happen without touching plan names directly. It's the same underlying idea as the pricing split: separate the stable concept (what a customer can do) from the thing that changes over time (what plan or price that's currently attached to).

FAQ

Related articles

Evaluate a SaaS Architecture Like a Staff Engineer

How We Implemented AGENTS.md in a Production TypeScript Monorepo

Your AI Agent Isn't Lying: It's Just Passing the Test It Rewrote

Idempotent Stripe Webhooks in Node.js TypeScript: Patterns That Survive Replay