Building Web Apps from A to Z, Part 1
This is the first article the series on how to build web apps. Today, we’re tackling the important issue of cashflow and the financial viability of your web app.
We’ve learned a ton about this issue because when we built DropSend, our first enterprise web app, we faced the same question; will it make us money? DropSend currently has 17,000 users and we’ve gained those in just over five months. It uses six servers which are co-located at 365 Main in San Francisco. It’s LAMP based and was built by three developers and one designer (with help from myself and my wife Gill). We had desktop apps for both Mac and PC built and both use our private API. It has taken us nine months to build, from conception to launch. The whole thing cost Â£35,000.
With so much at stake we had to be sure that DropSend would be financially viable and not just a bunch of web-candy for people to play with.
Is your web app going to make enough money?
Unless you are a large corporate company with money to burn, or a bedroom coder who is ‘just doing it for fun’ then before you begin building your web app, you need to ask yourself the most important question of all – will people pay money for it? It’s not materialistic to think about the money. If you don’t devise some kind of revenue model behind your app, you’re not being realistic. Let’s clarify that statement. If your app is just something that you’re building for fun, then it doesn’t need to be financially viable. If it turns into something valuable in the future, then great. Delicious is a good example of this.
However, if you’re putting a lot of time into your app and you plan to make a living out of it, it’d better have a solid financial model beneath it.
You’ll get 1% – 2% paying customers
If you’re offering a free plan to your customers (for example DropSend offers a free plan that enables users to send 5 free sends a month before they start paying) then expect to get around 98% or 99% of your customers on that plan. That means that you can only really bank on 1% or 2% of your total customers on the paying plan. In our experience this is true and other major players in the web app industry have agreed. This is about the industry average.
Many people (including ourselves before we built DropSend) vastly overestimate the number of paying customers they’ll get. Do the math. If you estimate that you will have 2000 customers in the first 6 months then work out how much money you will bring in if only 1% are on your paying plans. It’s that simple. Then, just to be on the cautious side, estimate how much money the app will bring in if you only get 65% of the signups you need. See our example cashflow spreadsheet below as an example.
The almighty cashflow spreadsheet
In your quest to find out if your web app is financially viable the first thing to do is create a cashflow spreadsheet. This can be done in Excel, but you can also use many free online spreadsheet tools like Num Sum.
A cashflow, for those of you who are not familiar it, is a simple document that helps you determine how much cash your company will have at any one time. Essentially, it just adds up your income for each month, subtracts your expenses for that month, and tells you if you have any money left in the bank. It’s definitely not rocket science, but it is essential to the success of your business.
The reason for creating a cashflow, is to help you see cash shortages coming, long before they hit you. This gives you time to adjust before you go out of business. If you would like more information on creating cashflows, there’s an in-depth article on cashflow at Signal Vs Noise. If you’re a small company, your cashflow should cover the current month and three months into the future.
Once you’ve created your cashflow spreadsheet, you need to plug in your expected revenues, month by month, and make sure you’ll make enough money to stay in business. Be painfully realistic. Be cautious and then reduce your expected revenue by another 35%. If your company is still cashflow positive (you’ve got money in the bank) even with this pessimistic outlook, then you’re good to go! If not, be very careful about proceeding.
Minimize the risk
A great way to minimize the financial risks of launching a web app are to build it as a “side project” to your paying work (be that a company, day job or whatever). If your company is already doing something that is bringing in cash, then keep doing that while you build your new app. This means you can launch your new app, hold your breath, and see if it takes off. If it flops, you’ve still got your bread-n-butter income coming in and you won’t go bankrupt.
The Credit Card Test
A great litmus test of the financial viability of your app is what’s called the “Credit Card Test”. Ask yourself if you would actually get out your credit card, punch in the numbers, start date, verification code and name. Is your service valuable enough for people to fork over their hard-earned cash, or is it just useful? There’s a big difference! If your app is not aimed at you then try to empathize. Put yourself in your users shoes and try to imagine what would stop you punching in the numbers. If you feel confident that your app is valuable enough that people will actually go through the hassle of paying for it, then it’s time to get busy building it!
The other factor that may affect the financial viability of your web app is competition. Do your research. How many other products are out there? Can you make yours better/different? Is a bigger company than you planning to launch the same thing? When will that happen? What is their ‘route to market’? Do they have marketing channels already in place? Take all of this into account. But the most important thing is don’t let it put you off. Remember, everyone thought there were enough search engines in the world, and then came Google. Everything can be improved upon.
In Part 2 …
In the next part in this series, we’ll talk about how to project manage the building of your web app and give you some tips and tricks for speeding things up. As always, please feel free to agree or disagree, by commenting below.