Here’s Apollos developers thoughts:
> Why not just increase the price of Apollo?
> One option many have suggested is to simply increase the price of Apollo to offset costs. The issue here is that Apollo has approximately 50,000 yearly subscribers at the moment. On average they paid $10/year many months ago, a price I chose based on operating costs I had at the time (server fees, icon design, having a part-time server engineer). Those users are owed service as they already prepaid for a year, but starting July 1st will (in the best case scenario) cost an additional $1/month each in Reddit fees. That’s $50,000 in sudden monthly fee that will start incurring in 30 days.
> So you see, even if I increase the price for new subscribers, I still have those many users to contend with. If I wait until their subscription expires, slowly month after month there will be less of them. First month $50,000, second month maybe $45,000, then $40,000, etc. until everything has expired, amounting to hundreds of thousands of dollars. It would be cheaper to simply refund users.
> I hope you can recognize how that’s an enormous amount of money to suddenly start incurring with 30 days notice. Even if I added 12,000 new subscribers at $5/month (an enormous feat given the short notice), after Apple’s fees that would just be enough to break even.
> Going from a free API for 8 years to suddenly incurring massive costs is not something I can feasibly make work with only 30 days. That’s a lot of users to migrate, plans to create, things to test, and to get through app review, and it’s just not economically feasible. It’s much cheaper for me to simply shut down.
> So what is the REAL issue you’re having?
> Hopefully that illustrates why, even more than the large price associated with the API, the 30 day timeline between when the pricing was announced and developers will be charged is a far, far, far bigger issue and not one I can overcome. Much more time would be needed to overhaul the payment model in my app, transition existing users from existing plans, test the changes, and have users update to the new version.
> As a comparison, when Apple bought Dark Sky and announced a shut down of their API, knowing that this API was at the core of many businesses, they provided 18 months before the API would be turned off. When the 18 months came, they ultimately extended it another 12 months, resulting in a total transition period of 30 months. While I’m not asking for that much, Reddit’s in comparison is 30 days.
> Reddit says you won’t get your first bill until August 1st, though!
> The issue is the size of the bill, not when it will arrive. Significant, significant charges for the API will start building up with 30 days notice on July 1st, the fact that the bill for those charges being 30 days from then is not important. If you hear that your electricity bill is going up 1,000x and the company tells you, “Don’t worry, the bill only comes at the end of the month”, I hope you understand how that isn’t comforting.
> What would be a good price/timeline?
> I hope I explained above why the 30 day time limit is the true issue. However in a perfect world I think lowering the price by half and providing a three month transition period to the paid API would make the transition feasible for more developers, myself included. These concessions seem minor and reasonable in the face of the changes.
I won't profit because I don't have an app. But all the other third party apps that won't shut down will just start charging and power users will pay for them, because they are better than the official website and app.
>Here’s Apollos developers thoughts:
The thoughts are fundamentally flawed. They're saying their owe existing users a service and can't charge them more for using the app. But... they're suggesting they will just refund them anyway. So, why can't they refund all users that are paying for Apollo and then reintroduce a subscription model. Those 50,000 that paid for Apollo beforehand will most likely renew their subscription that covers the Reddit API charges and nothing changes.
Probably what you’d have to do is close the current app and publish a new app with the new business model (subscriber-only at a higher price). The amount of people who would move to such app would only be a tiny fraction of the previous userbase (as most app users were free before), and now you keep having to deal with this chaotic company who could just change the rules again at any time with little/no notice. Plus you’ll never get the kind of reach you had before without the freemium model. I think most indie devs would likely choose to just quit and move on with their lives. If someone wants to buy his code from him and publish their own subscriber-only app, probably it’s an option.
I do not see them approving a mass refund just for a price increase.
Fortunately, this is covered extensively:
https://www.reddit.com/r/apolloapp/comments/144f6xm/apollo_w...
>Why not just increase the price of Apollo?
>One option many have suggested is to simply increase the price of Apollo to offset costs. The issue here is that Apollo has approximately 50,000 yearly subscribers at the moment. On average they paid $10/year many months ago, a price I chose based on operating costs I had at the time (server fees, icon design, having a part-time server engineer). Those users are owed service as they already prepaid for a year, but starting July 1st will (in the best case scenario) cost an additional $1/month each in Reddit fees. That's $50,000 in sudden monthly fee that will start incurring in 30 days.
>So you see, even if I increase the price for new subscribers, I still have those many users to contend with. If I wait until their subscription expires, slowly month after month there will be less of them. First month $50,000, second month maybe $45,000, then $40,000, etc. until everything has expired, amounting to hundreds of thousands of dollars. It would be cheaper to simply refund users.
Ok, so there's existing subscribers. They will have get new subscribers at a higher rate, and then wait for existing subscribers to renew at the higher rate before it will cover the API charges. Makes sense.
But they suggest they're just going to refund users. So why not just refund users and make a new subscription? This is what I don't understand. It's not a binary option here of closing the app or trying to cover existing user's API fees out of pocket. The middle ground of just refunding those subscribers and starting a new subscription exists.
The whole argument is that they will be out of pocket. But that is going to be the case regardless because they're going to refund users anyway.
> It's not a binary option here of closing the app or trying to cover existing user's API fees out of pocket.
You're totally right, it's not a binary option.
It's a calculated assessment of future prospects.