Charging monthly subscription for app - issues?

[CALocklin]

Does anyone out there have any experience with charging a monthly subscription for an application?

I can build time-limited registrations so I'm not concerned about that.

What I am concerned about are those things that someone who has never done it might not even think about. In other words, I don't know if there is anything to be concerned about but I've learned that doing something completely new often has its hidden issues.

- Perhaps problems arising from people who say they've paid but you don't have any record of it?
- Maybe people who want to pay ahead rather than monthly?
- Maybe a myriad of other issues?

One thing I need to keep in mind - if a client can't use the application any more, they will basically be out of business until they get all the data converted to something else. In other words, I will have to be careful about "unregistering" someone by mistake.

[Lenny Forziati]

You might also want to consider protecting your application from someone changing their system clock to get around an expired subscription.

[Tom Patten]

Hi Cal,

I have some experience with subscriptions and find it works quite well. I time out the app every 4 months. They get a count down of days to expiration when they log in within 2 weeks of the expiration date.

My intent, is to collect $$ and to have a conversation with them about how thing are working? I then give them a password that gives them another 4 months (or 2 weeks of the "chec is in the mail"), or converts the subscription to a license/purchase. Most convert to a purchase.

As more of us are developing applications and distribution methods, maybe we should submit a request for a topic at the upcoming ALPHA conference.

Tom

[CALocklin]

Have you had many problems with "checks in the mail" that don't show up?

I'm considering NOT offering a purchase any more. Or, if I do offer a purchase price, it would be about 50% higher than the current price which was a low, introductory price to start with. I'm planning a subscription price that is 1/30th of the "purchase price" plus a small amount for maintenance so they don't have to pay my hourly rate unless they ask for some major work.

I'm really curious if anyone has seen any guidelines on setting subscription rates?

The 1/30 number mentioned above (i.e, the full price would have been "paid off" in 2.5 years) is somewhat arbitrary but based on the idea that some clients will quit or go out of business before then so I can't reduce the price too much based on the assumtion that they will all be around 10 years from now - because many probably won't.

I'm also looking at the fact that my application should save a minimum of one full day per month for virtually any client and could easily save up to 3 days a month depending on how automated the client was to start with. If I assume a $15/hr employee (most customers are husband and wife teams so this is probably low), one 8 hour day would be $120 so I don't think it would be unreasonable to charge something in the $75 range. Not only will they save time but they will also be giving their clients better service even while spending less time doing it.

Thinking about the level of automation, I thought some of you might appreciate this: My first client was so automated that they usually only handwrote 5 3x5 cards for every order their clients placed and these were either handed out to installers or kept in card files for future reference - one file by date and the other by address. Building invoices at the end of the month was a matter of pulling them from the Date file and hand building up to 400 invoices; many of which involved multiple 3x5 cards. (They averaged about 80-100 individual orders per day.) Then they had to be re-filed so they would gradually migrate to the front of the file when the expiration date came around. Now, imagine that someone cancels before the expiration date and you have to find both the address card and the expiration date card so you don't end up calling them on the expiration date again. Sounds like fun, yes!?

In the middle of writing the above, I found this link to an interesting Inc. Magazine article on setting prices: http://www.inc.com/magazine/20050601/pricing.html