Oh my, @bee and I were chasing a bug today and decided to walk through this spec, mostly for fun since I think it’s super pretty, but maybe just in case it would be easier to actually do this than figure out this latest bug.
Well, instead @bee, in Her wisdom, found a potentially fatal flaw with it. Anguished wail!
I think I now see the Really-For-Real-This-Time Right Way to do this. Very quick sketch while it’s fresh in my mind…
(Oh yeah, first, the potentially fatal flaw is that if you pay for a bunch of, maybe infinite, months of Infinibee up front, then want to pay for just one month of Bee Plus, then go back to Infinibee, it should be impossible to pay more than the Infinibee-to-Bee-Plus delta for that single month. In my spec, we credited you for your unused Infinibee, you use some of that credit to pay full price for Bee Plus, then you have to re-buy your original Infinibee. Of course you earn interest on the credit and on net it’s super generous but if there’s even one scenario where you pay more than what’s exquisitely fair then clearly the whole thing is broken. Bee also pointed out two other problems: a perception-of-fairness problem, which might be overcomable, and a more fundamental problem that when you decide to upgrade, that’s the moment we should charge you, not after some upgrade credit runs out.)
So I pretty much had to concede that all that cleverness with upgrade credits was just wrong. The right thing involves remembering exactly what you paid for for exactly which future months and having no concept of credits or refunds. (I mean, not that kind of “no refunds” – just that refunds happen outside the system, with human intervention.)
Placeholder sketch of how that works:
Internally/conceptually, every user has a 4 by 1000 grid of checkboxes – one for each combination of plan type and month. Starting with this month, extending out to 1000 months (83 years) in the future. Everyone has all the checkboxes for every month checked for the free Core plan. When you add a plan or upgrade at some frequency, that means that starting now, for however long a period you’re paying for, you walk forward month by month checking the unchecked boxes and paying the time-discounted amount for that month for that box.
No boxes can ever by unchecked.
If you downgrade, the UI says “you are downgrading to plan X but still have plan Y until date D” where Y is the highest plan you have at the moment. Maybe that’s Beemium and at date D, because of whatever convoluted chain of upgrades and downgrades you may have done, you then have Bee Plus for some months after. That’s all fine. At that point the UI will change to saying “you are downgrading to plan X but still have Bee Plus until date D”. And maybe “date D” is actually “forever” if you paid for lifetime and that’s fine too. This is items #2 and #3 in the Philosophical and Implementation Notes of my spec above.
But everything is done by walking down that 4x1000 grid of checkboxes that can never be unchecked and that you always pay immediately for checking additional ones when upgrading.
PS: I’m kind of embarrassed that I keep doing this thing where I design an elaborate seemingly pretty thing and then find it’s all fundamentally wrong. I guess I can pat myself on the back for being able to see the wrongness despite having gotten all invested in it. Some would stubbornly dig in ever deeper!