Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

As an aside: developers often cite ongoing costs as a reason to charge in an ongoing fashion for services like, e.g., push notifications or web applications.

It doesn't particularly matter to me how you explain your business model to your users (although "Boo hoo we have costs and have to feed our children" has always struck me as less persuasive in prying money out of people than "Look at how much value we give you!"). However, as long as we're just developers here, I'd just like to point out that marginal users are too cheap to meter and as long as you're continuing to sell the service there is no reason you can't fund the server costs entirely out of present sales.

Example from my app so you can see I'm not blowing smoke: my VPS costs $85 a month. My users pay $30, once. Suppose, for the sake of argument, that I can tolerate 10,000 users in one day (which is absurdly low given typical peak concurrency for my application, but we're just playing napkin-math).

This means that $85 buys me 300,000 user-days a month. Trial users typically go up-or-out within 3 user-days. Paid users consume less than 5 user-days per month. (Far less in my case but hey, napkin math.)

Assuming I like keeping half of my safe allocation available for trial users (150k user-days or, as seen above, enough to support 50k new trials per month, which is more than 1.5k per day, which is more than 10 times my best day ever), this means that I can support up to 30k paying users on one $85 / month box.

Now, hypothetically, if I were getting 1.5k trials per day, I'd be getting somewhere on the order of 30 sales per day. 3 sales per month would pay for the server. It is clearly sustainable without having to use a subscription model.

I mention this mostly because some users groups are extraordinarily resistant to subscription models and I don't want anyone to feel they absolutely must, must, must price on a subscription if they offer a service.

I'm not intimately familiar with push notifications to iTunes apps but I suspect they require something on the order of one HTTP request. If so, on a per user basis, they're too cheap to meter. I'd (personally) offer them to everybody just to increase the amount of sales I got from the daily gravy train. (Well, to the extent that iPhone sales are driven by features, which I think is pretty darn limited.)

IMO, this breaks down due to the App Store's volatility. To compete, one generally (there are exceptions) has to lower prices to silly levels. That's fine and dandy when you're selling a couple hundred copies a day, but as soon as you fall off the chart in your category, you fall into the pit of selling 0-5 copies a day. At that point, not having a subscription model becomes unsustainable. There are 75k+ (and growing) apps on the store and a very small percentage of them actually get noticed. When they do, they often fall back into obscurity quickly. Very few apps maintain a solid rank for a year. You can't bank on getting sustained sales forever because you take the risk of having to foot the bill for the server yourself when the sales stop, VPS or not. Anyway, the feature is optional and the app works great without it. Apple recently added a listing that shows apps pulling in the most revenue. I think their hope is it will help alleviate this "race to the bottom" pricing. Time and market will tell.

As for push, there are two bits: client<-->server interaction and opening a socket connection to shoot data to APNS to send the notifications themselves. It was pretty fun to get together and really the hardest parts dealt more with business rules than integrating with Apple's service. I would personally have preferred APIs to hook into the phone's calendar app, but push is useful for IM apps and the like, in lieu of background processes.

I should mention the cost of our app is $0.99. It would cap out at about $2.99. I don't think asking for a dollar a year is unreasonable given the cost of the app.

I don't think there has ever in the history of the world been a consumer market where unit prices are so low.

BTW: Personally, regular payments (especially small ones), do put me off. But I wouldn't mind a prepaid model so much. IE, I pay for a month or six upfront and then pay again to renew. I know this kind of opt-in/out is rarely beneficial to vendors, but in some cases it might work.

low relative to what?

There's still an awful lot of the worlds population who earn less than $1 / day.

Most of them, presumably, do not walk around with $600 cell phones.

It can break down with any service. If you suddenly find yourself not really getting enough sales any more to justify continuing, if you have a subscription cost you can sit back and let things play out with your current users.

Otherwise your footing a monthly payment with no return. Also depends on what type of deal your running, people might be more than happy to pay a subscription given that they know the plug won't be randomly pulled on the service depending on future sales.

What user groups are extraordinarily resistant to subscription models? How do you know this? Not to get all [citation needed] on you or anything--heck, I am resistant to subscription models! I just figured you have some data (yours or someone else's) to back that up.

Teachers, for one, haaaaaaaaaaate them. A lot of educational software must be rebought yearly. I've used lack of recurring costs as a competitive differentiator for three years.

OK. But--all things must end. If, say, you did not have a desktop component, are you obligated to keep the service up--forever? That's a long time. I wonder if--like a not-bargain price--a subscription fee is an indicator (to a different group, naturally), that you will be around--at least for as long as people pay you. Otherwise, what's to stop you from grabbing the money and stopping the service?

Reply on news.ycombinator.com