Getting Rich Slowly
Since launching our new business model, a few people have asked us how we’ll fund the development of each new project. The answer is pretty simple: by being fast, keeping costs down and then using the revenue we generate from other areas of the business (such as our existing client apps) to fund it.
The whole idea here is to get rich slowly.
This new approach is our way of becoming a successful and profitable company on our own steam. And for that, we’re happy to take some risk now in order to reap the benefits later.
In the diagram above, we’ve illustrated how we plan on achieving this. To start, there’s the yellow band, which represents our consultancy work. This is made up of existing contracts and traditionally priced projects which we still do on a restricted basis. Because it’s directly proportional to the number of hours we can work, I don’t expect this to increase too much without making some new hires.
The different shades of blue represent the recurring revenue generated from new projects. To simplify the diagram, I’ve made a few assumptions about each new project:
- they’re completed at regular intervals;
- their usage increases over time;
- their value is roughly equal to each other;
- they remain in use for the foreseeable future.
Obviously this diagram is the absolute ideal, and I expect that in reality there will be a lot of humps and bumps in the smooth lines modelled here. But overall it represents where we want to get to as a company.
Slow Success is Better – And More Likely
We’ve all heard of the overnight successes like Twitter, Facebook, YouTube and MySpace etc. But hitting the big time is like winning the lotto. It’s a one in a million shot. The odds are stacked heavily against you.
You could also look at it another way and say that because of all the hype and media attention these companies receive, that budding entrepreneurs and business owners have an irrational expectation on the success of their own projects.
We’re Taking Our Own Route
Instead of trying to hit the big time, grab onto the next wave and hope for overnight success, we’re planning on becoming successful slowly. It’s a lot easer and far more likely then creating the next Internet sensation.
It may not be as sexy, but it’s steady, it’s deliberate, and we’re the ones in control.
Posted by Iarfhlaith | Link | Share
Trackbacks
Comments
6 Comments added. Add Comment?
Subscription models are often seen as the holy grail of web businesses because of the way that revenue build. However the model must include for churn. It would be interesting to hear your assumptions on churn rate. So for example if you can complete one project a month and loose 20% of your customers a year (they go bust, can track, no longer need your software, don’t pay you, etc.) then your revenue is capped at about 60 customers. This is something that I am talking about at barcamp belfast
Apr 21, 2009Absolutely right.
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!
Apr 21, 2009Caelen: I like to think of churn in terms of average customer lifetime. All customers will eventually die – actually or figuratively. The question is how long that will take. What really matters is the rate of growth. As long as the subscription rate beats the churn then you still have a winner. For http://www.taskfive.com the customer lifetime was about 3 months. For piehole – a lot of our subscribers have been with us from the get go.
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
Apr 21, 2009Hi James
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.
Apr 21, 2009Who owns the intellectual property for any web app built under your new model? I take it that webstrong do as you intend to offer the app to other customers?
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
Jun 26, 2009- 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?
Hi Niall,
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.
Jun 26, 2009Post a Comment