You’re partially right on this. Yes, we’d keep the IP on the project so we could resell the app to others (otherwise it wouldn’t be a feasible business model).

But for the moment, we’re not building these apps as multi-tenant systems, so the risk of bleeding data from one account to another isn’t a consideration.

Also, because each app is standalone (separate hosting, separate database) it’s a lot easier to customise them on an adhoc basis later on.

I think I’ve covered most of your concerns here, but I’m open to further suggestions on improving this model if you have any. The whole point of this business model was to make bespoke apps more affordable, less of a risk to the customer and to encourage people to ‘come out of the woodwork’ with their problems and ideas. Something that it’s definitely managed to do so far.

Some concerns I would have if I was to approach you to build a custom web app for me…

- The app would be built as a multi-tenant app which adds security concerns
- The conflict bewteen what I need customised to my needs versus your needs to build something quite generic so that it can be sold to other companies
- How do you handle requests for large customisations of my web app down the road?

Don’t get me wrong, I am a big fan of the subscription model. You raise some good points, one of which I would expand on:

“As long as the subscription rate beats the churn then you still have a winner”

This is true however it is difficult to achieve in the long run as the subscription rate is normally tied to resources. In the case of webstrong it is tied to the number of coders, in our case it is tied to the number of people in sales. However the number of customers that churn is a function of the number of customer they have (and the churn rate).

So the problem of churn becomes greater with the number of customers that you have, while your ability to add new customers remain static (assuming no new resources). This leads to a flatting of revenue with ever year.

In the instance where you add a customer a month and you have a 20% annual churn rate you loose 1 customer in year one, two in year two and 10 in year 5.

I like:
* Risk is diversified across several projects
* Suitable for automated payment (I’d require this)
* Can be funded from consultancy work
* Helps clients finance potentially expensive development

I don’t like:
* Clients may prefer not to be locked in (buy out clause required?)
* Software dev is hard and competitive (but that is just for me)

Of course you will find many software development houses charging a 15 – 20% maintenance fee anyway which is not that radically different from this model.

James

The reality is that there will always be customers that won’t pay, will cancel, or go bust. All I can do to minimise this is build a quality product and choose customers carefully.

I wouldn’t even attempt to make an assumption on the actual rate of churn. Because the truth is, I honestly don’t know what it’ll be.

20% seems a fair enough assumption, but time will tell. Maybe I’ll do a follow up to this post in a couple of months and throw out some actual figures. Would people be interested in that?

Best of luck with your talk!