Language-wise, to be clear, it’s not a credit in the sense of a credit balance. It’s just us taking account of existing unexpired subscription at the point of changing plans.
I think I want to implement it as a literal credit balance, just that it can only be used for future premium payments. You can’t withdraw it or use it to pay pledges.
(Btw, this is all in mass flux at the moment as I work out the right way to do it.)
Implementation detail. Talking about credit balances sounds too much like holding client funds to me.
Also, exquisite fairness to one side, remember that somebody has to implement and maintain the code to run this scheme. If elegant simplicity falls out the other side of this flux, then I’m all for it.
What else could you obsess over that might improve Beeminder more than getting these edge cases perfectly and automatically right?
Speaking of edge cases, I’m one of them, on a lifetime subscription to Plan Bee at the original price-point.
I don’t remember what I paid all that time ago, though I can guess, look up, or calculate it if I cared. It seemed like a good deal at the time, so I went for it.
Likewise, when I go to the premium page now, I get offered a price to change plans. It’s either a price that I like, or a price that I don’t, in relation to my perceived value for the feature difference and my qualitative level of love for the bee.
The actual numbers now vs the numbers then mostly don’t come into it. It’s either going to seem about right (or not) and feel fair (or not).
Speaking of Exquisite Fairness, this is a very fair question! But I think I just figured it out and it’s going to make things simultaneously simpler and better than the status quo. Also I feel honor-bound to make sure we’re following through after my talking up all the Exquisite Fairness. Also I got obsessed / nerd-sniped.
How we’re handling this: We’ve already done the refactoring and update queries in the database to store the nominal amount of Plan Bee when you got it, plus any promotional discount you may have used (these were implicit but confusing before). You’ll now (ish) be able to upgrade and get the full original amount you paid as a credit (since you’ve used, technically, 0% so far of the infinite amount of Plan Bee you paid for). On your new fancier plan you’d just not pay anything until that credit was used up.
Grandfatheriness aside, if you were on lifetime Bee Plus and wanted to just try a month of the $32/mo Beemium plan you could do that by upgrading to monthly Beemium and immediately downgrading back to lifetime Bee Plus. That would cost exactly $32 because you’d use up $32 of your upgrade credit and then have to supplement $32 to get lifetime Bee Plus again.
That’s not quite as nice as originally where the lifetime plan is permanent and just reduces the cost of any upgrades. To make up for that, credit balances grow exponentially. As they should, per exquisite fairness.
Hopefully this will all be more intuitive in the UI than it is in prose!
OK, so just to let you all know, the current implementation is not entirely broken or anything.
Here are things that work:
lifetime upgrades: if you upgrade to a higher plan after purchasing a lifetime plan at a lower level we reduce the monthly price of the higher plan by the nominal monthly price of the lifetime plan you purchased. So, e.g. with a lifetime infinibee plan, an upgrade to Bee Plus would use $12 (rather than $16) for the nominal monthly price. Then any coupons or slider discounts would be applied to that base price.
downgrades and frequency changes: we let the current plan run out, and then make the changes. So if you had purchased a month of Beemium, and then a week later downgraded to Infinibee, we’d wait until that month ran out, and then we’d drop you down to Infinibee and charge you whatever price / frequency you had purchased at.
upgrades: Upgrades happen instantaneously. We give you a discount on the first payment by prorating the remainder of the latest payment from your current plan. I.e. if you paid for $4 for 1 month of infinibee and then 3 weeks later upgrade, you’d get (4 * 1/4) = $1 discount on your first payment for the upgrade (which happens right then). Or if you paid $16 for one month of Bee Plus and then immediately upgrade to Beemium, you’d get (16 * 1) = $16 discount of your upgrade price.
Here is what is broken:
These are not perfectly mathematically general and all elegant and stuff, but they are, I believe, sufficiently Fair, except for one bug case, with upgrades. If your prorated discount is greater than your upgrade price, we discount the first payment to $0, but then you lose the remainder of that credit.
Here’s an example of that bug in action: you buy 4 months of BeePlus for $61 / 4 months, and then immediately upgrade to monthly Beemium, i.e. Beemium for $32 / 1 month. Then you’d get the first month for free, but you’d lose that extra $29 of discount credit.
So Danny’s spec fixes this, but the broken case is sufficiently rare at this point in time that there’s a much lazier immediate solution which is to blast off a big airhorn and throw an exception for ourselves when the discount > payment, and then we can manually intercede to make it fair.
Dang, @bee, that was an impressive feat of yanking me out of that rabbit hole by the ears! Seriously, very elegant(ly expedient) stopgap. I’m still super enamored with my spec and want to implement it later  but thanks to your wisdom and pragmatism (I’m still being entirely serious!) there’s no longer any urgency to do it Right Now before we inadvertently cheat someone. I mean, relative to the Exquisite Fairness we’ve been crowing about. It’s all so insanely more fair and generous than any other company in existence  that it’s pretty funny to be quibbling at all.
But now we’ve got the best of all worlds!
 Also it eliminates so much cruft and spaghetti with special cases for lifetime plans and stuff.
 Well, I guess companies who are smart enough to not create rabbit holes like this in first place by following KISS from the start can be equally Exquisitely Fair just by not having any messy upgrade/downgrade/discount/frequency corner cases. (That discount slider is sooo sexy though…)
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!
Watch out for the Y2.102K bug!
I only gave your post a glossy-eyed glaze over but I am quite confident that you’re the only business people in the universe attempting to make plan upgrades and downgrades even remotely fair or user friendly. So you’re essentially in uncharted waters here => you probably shouldn’t feel embarrassed about not acing the design on your first try.
Another thing to think about would be “How many months of free Beeminder could I give our current premium users for the price of my salary-hours invested in designing premium plan pricing?”
Yes, @bee and @mary and I were just talking about the startup egg-basket principle and how if very hypothetically we had a time machine it probably would’ve been prudent to nix the whole idea of premium plans altogether. It was a form of diversification from our existing monetization strategy and startups should almost never do that. Again, all totally academic now (as is most of this whole forum thread!) but the amount of time and effort and confusion and whatnot that premium plans have caused has very plausibly exceeded the revenue they’ve brought in, not even counting the additional revenue we could’ve created with all those hours of our lives.
(also true that we made it all way more complicated than we needed to with auto-canceling and half a calculus book’s worth of math in the discount slider, but those are very much the tip of the iceberg in terms of aggregate confusion for us and users, UI complexity, bugs, etc, compared to the universe where there just was no such thing as premium)
PS: If we ever wanted to actually consider scuttling premium plans it would be a pretty huge amount of work, even just deciding for sure that it was a good idea in theory, let alone in practice, with making things fair for people. E.g., what’s the value of being able to say we have a charity option, support savings from paywalling confusing features, etc, etc.
PPS: Probably the efficient/elegant way to implement the grid of checkboxes is with interval trees.
So how does the startup egg-basket principle work and why should startups not offer premium plans?
I can’t imagine how this statement (that is, that the premium plans weren’t worth it) could be true. If you gave all free users all features your revenue would be significantly reduced, as many of the features make it so users don’t have to pay as much in penalties.
On the other hand, if you didn’t even have those features, beeminder would be much less useful, and fewer people would use it in the first place and more of the ones who did would quit. (Beeminder would be useless to me at the free or lowest levels.) Those features are a big part of what attracts users.
It’s also not clear to me that your time and effort could have been used more efficiently by getting more users to pay more penalties for the crippled product beeminder would have been - that is, my guess is that the number of users is a function of beeminder’s and the beeminder community’s organic growth over time, rather than something you can achieve in a big block all at once through having shoved in more hours at a point in time in the past.
Unless you mean charge everyone a constant monthly fee from the beginning? But then you may have gotten much fewer users from the beginning.
But what about the complexity and bugs from the features or other settings you might have added or changed instead, not to mention fielding requests for adding the premium features?
So basically, although I realize I’m very biased because I love the premium system, and I realize there is some status quo bias here, I can’t see how this could be true.
Cool - I’ve never seen those! I’m not sure that makes sense for this option with discrete check boxes though, because you have to keep track of the cost of each check box as it changes over time, add up the costs of different check boxes, move the array forward one month every month, and so on, all of which seem to suggest using a 2d array instead, since you’re dealing with monthly rows you’ll be iterating over rather than arbitrary intervals.
Sorry, I was way too vague! The startup egg-basket principle is: put all your eggs in one basket. Most startups should focus exclusively on their premium plans and arguably not have a free plan. Ie, focus on the one most promising thing for making the startup sustainable. Beeminder already had that – pledge revenue – and so, by strict adherence to the egg-basket principle, should’ve doubled down on it.
I think the rest is too hypothetical to worry much about but one example is we could’ve really gotten brazen with the derailing is not failing philosophy and said that you can unlock premium-like features by derailing more. I think I’m kidding but honestly can’t tell right now!
But it sounds like that wasn’t sustainable without a premium plan, because you’d have to either cripple features, or accept the revenue loss for having those features without having premium plan revenue make up for it.
You’re already doing this partially and informally by offering discounts for premium plans based on derailing pledges, right?
And don’t forget, doing it that way would have its own “aggregate confusion for us and users, UI complexity, bugs, etc.”
For the record, I love auto-cancelling.
I am decidedly Not Good™ at phoning up and cancelling things, and only marginally better at cancelling online. There are loads of things (cough Complice) still-being-paid-for that I have yet to get around to cancelling.
In some cases, (cough Complice), I think the service is brilliant, and that my personal deficits keep me from making the most of the awesomeness.
For the avoidance of doubt, (cough Complice) is the least of the outstanding things in my avoidance queue…
Yeah, autocanceling is really key for showing that beeminder is trustworthy - I think the effort that went into that was definitely worth it.
Off topic a bit. I also love complice, but keep bouncing off of it. I know that an Adam that sticks with it would be a better and happier me, but…
I took a Goal Crafting Intensive last weekend with them, and I think after I complete the exercises, I’ll have a better time.
I’ve found BAAS really helpful - Complice was hard for me to get into and I don’t like how it forces you into its “small number of goals” model. Also the way it only works through a web browser makes it difficult to use. The GCI exercises can be helpful (I was there and did a little of them) but also seem geared toward the same model.