When do you stop grandfathering old pricing?
Hey Indie hackers, I’m trying to figure out the right way to handle grandfathered pricing and would love to hear how other founders approach it.
Over the years, we’ve run several pricing experiments.
One rule we’ve always followed is that new pricing only applies to new customers. Existing customers keep the plan they originally signed up for.
Some of our customers have now been paying the same price for more than three years.
My thinking was that customers made their decision based on the product, packaging, and price we offered at the time. It didn’t feel right to make them pay for our pricing experiments.
The downside is becoming more obvious now.
We have legacy plans to support, billing gets more complicated, and some of our oldest customers pay the least despite receiving a much more capable product than when they originally signed up.
The approach I’m considering is:
- Keep customers grandfathered while we’re experimenting with pricing.
- Only migrate them after the product or packaging has changed in a meaningful way.
- Give plenty of notice and make the transition as fair as possible.
I’m curious how you handle this. Do you grandfather customers forever, set a time limit, or only migrate them after a major product or packaging change?
I like that you're treating grandfathering as a trust decision rather than just a pricing decision.
The interesting question isn't when customers should pay more. It's what promise you believe you made when they first bought. Answering that makes the pricing decision much clearer than optimizing around billing complexity alone.
Exactly. The promise wasn’t necessarily “this price forever.” It was “we won’t make you pay for our pricing experiments.”
If the product or package changes materially, that may justify a new agreement. But the transition should be explicit, fair, and communicated well in advance. That framing is much clearer than treating legacy plans as only a billing problem.
I'm glad it resonated.
Reading your reply gave me one thought about what happens once customer promises become part of the product itself rather than just the pricing model. I'd rather explain it in the context of what you're building than try to condense it into a few comments.
If you're interested, what's the best email to reach you on?
Hey Roman — following up with a quick offer: CancelKit is close to launch (billing setup wrapping up this week), and I'm opening a handful of early access spots to indie SaaS founders — free during beta + a lifetime discount for the first 10. Given the pricing-change churn angle above, thought it'd be worth having in place before you migrate anyone. Let me know if you want the details.
One operational lesson: treat this as a data migration, not only a pricing announcement. Separate entitlements from price IDs first, then build a migration manifest per customer: current price, target entitlements, proposed price/discount, renewal date, notice date, and expected next invoice. Dry-run the billing output before changing anything.
I’d canary the change with a small, representative cohort and reconcile four systems afterward: billing subscription, product entitlements, CRM lifecycle/owner, and customer communication status. The failure you want to prevent is not just churn; it’s someone being charged the new price while still receiving legacy entitlements (or the reverse). Keep a rollback path for each account until the first invoice settles.
For the decision itself, cohort data helps: contribution margin, support load, active usage, tenure, and feature adoption. That lets you preserve genuinely valuable early-customer goodwill while sunsetting plans that are operationally unsafe.
We use this manifest-and-reconciliation approach in Atlantic’s cross-system CRM workflows. Disclosure: I’m Ege, co-founder of Atlantic, sharing our implementation experience.
Thanks, this is a useful distinction.
The per-customer manifest and rollback window through the first settled invoice are especially practical. Even a fair pricing policy can damage trust if customers receive the wrong access or invoice.
grandfathering is usually cheap goodwill, so id keep it as the default and only break it where it actually hurts: a cohort thats unprofitable to serve, or a legacy plan blocking your roadmap. two moves that beat a blanket change: 1) migrate by offering more, not charging more, give legacy customers a new-value reason (and a small perk) to opt into the current plan, dont force it. 2) the real pain is usually the number of legacy plans, not the prices, so collapse those into fewer SKUs and billing stops being a mess even if some keep their rate. only hard-sunset the plans you genuinely cant maintain, with a long runway and a clear why.
That distinction between preserving the rate and preserving every legacy SKU is very useful. We may be treating them as the same problem when they do not need the same solution.
You're debating when. The sharper question is what you actually promised. Three years ago the deal was "this price for this job" it was never "every capability we ever ship, at old rates, forever."
So your instinct is right: tie migration to a real packaging change, not a calendar. When the product has meaningfully changed, move everyone onto current plans and make tenure visible in the price a permanent loyalty rate that keeps your oldest customers the cheapest people on the new tier. They stay insiders. You stop maintaining a museum of plan definitions.
The fear is bigger than the data here. Migrations with a long runway and a concrete "here's what you've gained since you signed up" note churn far less than founders expect, and the accounts that leave over a fair increase are usually the ones costing the most to support. What breaks trust isn't the increase. It's the surprise.
One rule to add: never migrate mid-experiment. Migrate once, deliberately, tied to visible product change. Repeated resets teach customers your pricing means nothing.
I agree that the calendar is the wrong trigger. The original promise covered a specific product, package, and job, not every future capability at the same rate forever.
Grandfather the price, not the packaging. Keep their dollar amount frozen but move everyone onto the current plan structure, because the real cost of legacy plans is engineering and support carrying five billing configurations, not the discount. And when you do migrate, give 60 to 90 days notice; most customers accept a fair increase, they just punish surprise.
Thanks, notice period with a clear explanation of what changed feels much fairer than an unexpected invoice.
One angle the others haven't hit: a "legacy plan" bundles two separate things, the rate they pay and the plan object your code has to keep alive. You can usually keep the first and kill the second. In Stripe terms: move a grandfathered customer onto the current plan's entitlements, but preserve their old price with a custom price or a permanent coupon. They keep paying less, you stop carrying a distinct plan definition through every future change. That turns "how long do we grandfather" into a one-time data cleanup, without changing what anyone pays.
Thank you, I need to check how cleanly our billing setup supports that, but conceptually it solves the trust and maintenance problems.
Check your own gating code before you check Stripe. If entitlements switch on price ID, that's the coupling that makes legacy plans expensive, and no billing trick fixes it. Move entitlements into your own table keyed by plan rather than price, and the price goes back to being just a number on the subscription.
After that Stripe gives you two ways to freeze the rate. A permanent coupon (duration: forever) is the auditable one: the discount lands on every invoice and you can list exactly who holds it. Ad-hoc price_data on the subscription item works too, but those prices never appear in your Prices list, so a year on nobody can answer "who's on a custom rate?" without walking every subscription.
I'd take the coupon for that reason alone.
the framing that helped me: grandfathering isn't a pricing decision you make once, it's a maintenance liability you renew every release. the revenue you forgo is visible and small. the hidden cost is that every legacy plan is a distinct state your billing, gating and support code has to keep alive forever, and that set only grows. three plans is fine, twelve is a tax you pay on every future change.
so i'd tie migration to two things, not the calendar:
on fairness: when you do move someone, lead with the capability, give a long runway, and keep them the cheapest in their new tier with a loyalty rate. the goal is 'you're still paying less than anyone else here,' not 'we raised your rent.' people accept increases tied to visible value and resent ones tied to your spreadsheet.
I like the idea of a hard cap on active plan definitions. It is useful because it creates an operational rule instead of leaving the decision subjective.
Concrete rule I would use: grandfather the customer's economic promise, not every old billing artifact forever.
If the plan they bought still maps cleanly to a current package, keep it. If the product has materially changed (new support load, new usage ceilings, team features, compliance work, etc.), create a migration path: 60-90 days notice, show exactly what changed, offer one annual renewal at the old price or a fixed discount for 12 months, then move them to the closest current plan.
I would also keep a tiny exceptions list for customers where the original sales promise was explicit. That protects trust without letting legacy plans become a hidden support tax.
Thank you, notice period looks great.
I'm not a developer, but I've seen a similar issue from the product side.
One thing we learned is that grandfathering is not only about keeping the old price. Customers also form expectations around usage limits and included benefits.
In one case, pricing and usage allowances had to be adjusted because operating costs increased and the product had changed significantly. Even though customers were given a reasonable transition option, some still felt disappointed because the change affected what they believed they had originally purchased.
That experience made our product team much more cautious about long-term pricing promises.
My view is that grandfathering forever can create real operational and financial problems, but migrating customers should not come as a surprise. It helps to define from the beginning which parts of a plan are permanent and which may change as costs and product capabilities evolve.
For major changes, I think plenty of notice, a clear explanation, and a meaningful transition benefit are just as important as the final price itself.
Most people raise their prices in line with inflation. If inflation is 3%, raise your prices by 3%. It might be a good idea to email existing customers to let them know you’ve raised prices due to inflation and include a new service in that price.
Thanks, good rule, and customers are ready for raised prices.
Following this closely since I just launched SlideRoll (photo cleanup app) with subscription pricing and haven't hit this decision yet, but I know it's coming. My instinct going in is closer to your original rule — people subscribed based on a specific price/value tradeoff, and retroactively changing that feels like breaking a small trust contract even if it's technically allowed in the terms. The thing I keep going back and forth on: does grandfathering become a harder call when new pricing reflects real cost changes (App Store fees, infra, etc.) rather than just repositioning? That seems like a genuinely different case than "we decided to charge more for the same thing."
We've watched this from the other side - CancelKit sits on the cancel button, and price-migration notices are one of the most reliable churn spikes we see. A couple patterns that seem to help: pairing the migration email with a real "lock in your old price for N more months" option softens it a lot, and silence hurts more than the migration itself - customers who get 60+ days notice with a clear "here's what we've shipped since you signed up" reason churn less than the ones who just see a bigger invoice one day. If you do migrate, it might be worth treating that window as a deliberate save-offer moment, not just an email.
Your instinct to migrate at a packaging change is right, and I'd make it the rule: grandfather the price, never the plan. When the product changes meaningfully, move legacy customers to current plans with 12 months at their old rate, then a discounted bridge to current pricing. I ran a version of this for years in my services business, and the customers you lose in a fair, well-noticed migration are usually the ones costing the most to support anyway.
This comment was deleted 20 days ago.