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.
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.