Unfortunately no, I’m not able to estimate the amount of time until I’m done implementing subscriptions. I can share why though:
Why it’s very hard to estimate
It’s a tricky thing for me to estimate to begin with because I haven’t implemented an entire payment system before so it’s hard for me to get a good grasp of all the intricate details that’s required. I could come up with a halfway reasonable estimate despite that (which I attempted to do a couple time last year as I’ve shared) but this first part of the estimation process is always in terms of some “unit of work”.
To convert from this unit of work to an actual duration of time, I need to know how many units of work I normally get through each week.
Unfortunately the amount of work I get done each week has been wildly inconsistent for a pretty wide range of one-off and recurring reasons.
So I’ve got a challenging estimation problem to begin with on one side of the estimation process (figuring out the units of work required to complete the project) and then on the other side I’ve got a challenging conversion (figuring out how many weeks it will take to get through my pile of units).
Since there’s no particularly strong reason for me to keep attacking this unusually hard estimation problem, I’m not going to.
What’s left?
I can share, roughly, the actual work that’s ahead of me though if you’re interested. This is some seriously nitty-gritty details though (despite still being quite rough 
).
- I’m currently finishing up the resubscription flow. I’m a good chunk of the way through it right now, and it’s fairly similar to just subscribing for the first time with an existing Shmeppy Player account, so it’s really just a few tweaks within the scaffolding I’ve already set up.
- I’ll need to smash at the subscribe during registration (which is already implemented) followed by various unsubscribes/resubscribes on the account page to try and shake out bugs. This’ll involve manual testing and the account page subscription actions aren’t covered by automated testing well yet so I’ll do a bit of that as needed.
- I need to create a payment history page. I haven’t even started on that.
- I need to create the “your last payment failed, gimme a new card” flow and alerting. Pieces are in place to facilitate this but nothing user-facing yet.
- I’ve implemented automatic refunds on unsubscription if the user hasn’t received a refund before, but I need to expose the terms of that to users somehow. This’ll involve drafting a clear description of the policy and writing takes awhile. I’ll also need to find a place to put that writing and direct users to it. Fortunately the policy is pretty simple (you get a refund if you haven’t gotten one before)… so fingers crossed that this won’t actually take too long.
- I need to create a new read-only mode for a map that is owned by a previously-subscribed Player account. It needs to only be accessible by the owner. This’ll be pretty annoying to implement I’m sure because it’ll be a different mode that the toolbar will be in.
And then after all that is done (and all the things that I’ll realize I need to do as I do all these things) I’ll have an untested system that charges real money from real people. So I’ll probably deploy it to a test site like “paid.shmeppy.com” and then make a callout for beta testers who’re willing to pay for Shmeppy completely unnecessarily just so Shmeppy can fuck up somehow and I can fix it.
Alternatively I might test it in a less rigorous way initially and then just put it on the main site with a large “free initial period” where existing users have quite awhile before they need to actually subscribe. That way the number of paying subscribers should grow fairly slowly and I’ll be able to work out the bugs that way.
There’s advantages to both testing strategies. I’ll make an actual decision between them (or perhaps between even more options) when it’s time to actually do that.
) after which they’ll be downgraded to a Player account unless the user subscribes.