Ask HN: When you sell a server-based iPhone app, how long should it work for? | Hacker News Reader

Ask HN: When you sell a server-based iPhone app, how long should it work for?

10 pointsamichail6 comments

How long are you expected to keep the server-side working?

What if the app is still functional but with reduced functionality without the server-side working properly?

I would say it depends upon what is it for, how much you sold it for and what claims you made when you sold it to the customer.

We are lining up server side apps for test preparation. If we ever stop server side, we will stop selling the app 3 months prior to server halt, post a notice about the same and boom.

what claims you made when you sold it to the customer

Very important this one.

I think it also heavily depends on whether the mobile app and the server side are complinentary, inter-dependent, or redundant.

For example if your web service was a way of managing say, your stamp collection and your app was just a way to browse it offline; that would be a lot worse than if your app was a standalone game, and the server side was just a way for people to list their high scores in public.

But, obviously some people are going to be mad anyway, since they had some expectations that you will no longer be meeting.

If you want to ensure better degradation, you could upgrade your app to be more usable without the server. Drawing on your stamp example, you might add client-side stamp storage and backup features. If the server goes offline, then you could even continue selling your app that way. I would not implement those features too early, though, since obviously you don't want to cannibalize the rest of your service.

this is exactly what we are doing. we are updating our app through server side but will keep all the files on the iPhone itself.

Can't you just use a subscription model? Give the customer a certain time (say, three months or one year) and start charging after that. This way, they won't feel as if you are taking something away from them when you pull the plug, and the service may actually be able to go on with this extra revenue alone.

Set expectations fairly. Ensure degradation when server goes away is understandable. (For example, maintain a 'discontinued' message at a more-permanent URL as a fallback.)

Reply on news.ycombinator.com