In this 30 minute video from the FOWA Tour, you’ll learn the key points you need to consider when deciding on the business model for your product or service.

Topics include …

1. Finding your niche
2. Should you charge or go ‘Freemium’?
3. Understanding the psychology of free
4. Agile business development

[Update: You can watch the video, download the MP3, subscribe to the audio or view the slides.]

[Editor's Note: We'll be covering topics like How to Build a Web App from A-Z and Kick-ass Online Marketing Techniques at FOWA London.]

The Video

Presentation slides

You can also view Roan’s slides below …

Photo Credit: flickr.com/photos/kimberlyg

“There will always be a company that replaces you. At some point your BlackSwan competitor will appear and they will kick your ass. Their product will be better or more interesting or just better marketed than yours, and it also will be free. They will be Facebook to your Myspace, or Myspace to your Friendster or Google to your Yahoo. You get the point. Someone out there with a better idea will raise a bunch of money, give it away for free, build scale and charge less to reach the audience. Or will be differentiated enough, and important enough to the audience to maybe even charge more. Who knows. But they will kick your ass and you will be in trouble.”

- Mark Cuban

We’re not completely against the Freemium model for web apps (heck, that’s what made DropSend really succeed for us) but there are some important things to consider before taking this route. Here are a few great resources to checkout when deciding on your web app pricing model:

1. Freemium did not work for Phanfare
2. When you succeed with Free, you are going to die by Free by Mark Cuban
3. Jason Fried on why Free is the Future of Failure. Jump to minute 9:15 on the video or audio.

Pricing is always somewhat of a black art, and a subject about which there is precious little written with regard to web applications. It’s something I’ve always been fascinated by. The question of how to price our web application, Litmus, was subject to countless hours of discussion. Here I’ll discuss some common factors and hopefully help spark some ideas which can help you decide upon the price of your own application.

Billing cycles

Hobbyist, consumer products (think Flickr) often charge annually rather than monthly. If your monthly fee is only $3 it’s going to be easier for everyone involved to charge $35 a year, rather than bill in such small increments. For this article I’ll focus on services billed monthly.

Price plans

Most services have a range of price plans to cater to different customers. This is basic market segmentation — getting the most money from the people who can afford to pay more.

In my opinion it’s good to keep the number of plans down to about 3 or 4. With more than that it becomes more complicated than it needs to be. Harvest do a nice job with three very straightforward plans.

DropSend’s pricing could be considered too complex. The gap between $5 and $9 is very small. As a business purchase, if I’m willing to part with $5 I’ll be willing to spend $9. I’d suggest dropping the $5 plan and just go straight to $9.

Price points

If you look around at other web applications, the monthly fees tend to hover around similar price points:

• $5
• $10
• $20
• $50
• $120

Doubling the price with each plan feels neat. That said, it’s important that the value provided increases proportionally to the price, or better. Take Basecamp: $12 for 3 projects, $24 for 15. Feels like a good deal.

For our service we presently have two price plans — one around $50 and one around $150 (I say “around” because we bill in Euro). Customer feedback seems to indicate that people would appreciate a more limited, lower-priced plan. As a result, we may add something around the $20/month mark. This is in keeping with the price points above, yet keeps our total number of plans straightforwardly small.

Setting the price

Two years ago, when we first launched, we priced ourselves slightly under our main competitor, Browsercam. We pretty much took their price plans and reduced them slightly.

I don’t think that’s the right way to go about it. As other people have said before me, the price sends a message about the quality of your product. We feel ours is better, so in reality we should be charging more (we now are).

Usually for web applications the costs involved are fairly minimal. It doesn’t make sense to use what’s called “cost plus” pricing — setting your prices X% higher than it costs you to deliver the service. Instead, some things can be justifiably more expensive because of the value they add, or the time they save. In our case the target customers are web designers. They might charge in the region of $30-80/hour. A Litmus account will cost them about $50/month, so as long as we’re saving them more than an hour of time each month, it’s definitely a worthwhile purchase.

A friend of mine once told me to make customers feel like heroes. That might be being a hero in front of their boss, their client, or their peers. Tools which help people look more professional are extremely valuable to them. Aspects of a product that enhance the customer’s image in the eyes of someone important to them will in turn cause them to value the product more highly themselves. For us that aspect was our customers’ ability to publish their test results on an elegantly designed web page. That’s something our users can show their clients and feel proud of — it makes them look better. (It’s also something that some of them charge their clients extra for, as part of the total project cost.)

Differentiating price plans

With Litmus, we know from experience that we have two types of users: freelancers and agencies. Freelancers (I used to be one) don’t have as much to spend as agencies, obviously. We needed to segment our pricing in such a way that we extracted the money from agencies who could afford to pay, but still made the service affordable — and usable — for freelancers. The difficult question was how.

Limits

Perhaps you’re lucky and have an obvious limit on the usage of your application which would work to differentiate customers. Or perhaps each time they use your service it directly relates to them making more money (think Blinksale and the number of invoices you send). It’s not always that simple.

We didn’t want to limit the number of tests people could perform. If you’re fixing a site it would be frustrating to run out of tests. We came up with an alternate solution — limit the number of pages or emails you can be working on at one time. Agencies will be working on lots, whereas freelancers will be working on just a handful. When you’ve filled up your “slots” you can delete them to make room for new projects. In a team situation that’s not viable as you’d be constantly asking other people if you could remove their tests. Additionally, agencies would be working on more than a handful of pages or emails at once. Therefore, in theory, we’ve successfully divided our customers into two segments: those who are testing a handful of things at one time, and those who could be testing far more.

Features

High-priced plans can make up a very large portion of overall revenue. I’d suggest having a more expensive plan that suits businesses that have more money to spend (such as design agencies in our case). Here are a few ideas for features you can include in a high-priced plan to help it stand out to those types of buyers:

• Multiple users
• Priority email support (or telephone support)
• SSL security
• Custom branding

We added SSL and functionality for multiple users to our plan aimed at agencies. For you, the other features mentioned may be more or less useful depending on your application.

Summary

I hope some of the above thoughts and ideas are useful. I’d love to discuss them further in the comments. This is an area which often gets overlooked so please do join in the discussion and add your experience.

You know the feeling. You’re visiting an interesting website that has a service you think might be useful, but there is no way to try it out properly without parting with your hard-earned cash. And often, even if they do have a trial option, it’s set up so poorly and requires you to give up so much personal information that you give up and go somewhere else. No thanks, I don’t want to give you my home phone number.

Pingdom, my company, had long planned to include the possibility for prospective users to try out the service for free before signing up for a full account. After analyzing the different kinds of trials available for a large number of services around the internet, we felt that we had found our success formula. Even in retrospect, the few simple rules we came up with have worked really well for us. Not all online services are created equal, but I think that our approach is generally enough to suit almost everyone.

So what is this success formula I’m talking about? We’ve narrowed it down to four simple rules for how a free trial of an online service should work. Let’s go through them one by one.

Signing up for a trial account should be easy and painless

This may seem like a no-brainer, but all too many companies require you to enter a significant amount of information about yourself before allowing you to try them out. Have you ever tried signing up for something only to be met by a huge registration form with lots of required fields? Most likely yes. How did it make you feel? That in itself should tell you not to do the same yourself.

Never make someone who is interested in your service jump through hoops to get to it. Instead, go in the other direction and make it even easier to sign up for a trial than it is to sign up for the vast majority of the free email services out there.

Do not require trial users to enter their credit card information

Anyone wanting to try out your service should be sure that there is no commitment involved. Requiring a credit card sends the wrong signals.

This is a shift in mentality from services where you actively have to cancel your account before the trial ends or be automatically charged for the next month. Users should upgrade their accounts themselves, making an active choice. You can remind them about it, and if you want to sweeten the deal by offering discounts or other offers, that is fine, but make sure the customer feels safe. Let them know that their account will just expire by itself after X number of days unless they themselves choose to upgrade it.

Do not cripple the trial

There should be no blanked-out options or missing features to stop the user from fully evaluating every aspect of your service. It is very common to cripple the features available during a trial, but the potential customers want to see everything you have to offer, and you should let them. Give them what any regular, paying customer gets, but for a limited period of time.

Though perhaps not obvious, this should also include support. Depending on the nature of your service, support can be a crucial part of the user experience, and an important part of their evaluation of you. Make sure that you address the needs of your trial users as well as your regular customers. Think of them as customers in the making.

Include a "highlight bonus."

Depending on how your service is built up, this fourth point may not be essential, but if you have add-ons and extra functionality that users pay for, this is a great way to make the trial more attractive. If a visitor is looking at your trial option, have something that will tip them over the edge and dive in.

The trick here is to pick a bonus that really highlights an important feature of your service. That way you are not just randomly spending money to add another feature checkbox for the trial option. Note that it doesn’t have to be anything huge. In our case, for example, the bonus is 20 free SMS alerts, which helps show users the full potential of our site monitoring service during the trial.

In the rear-view mirror

When we launched our free trial option, sign-ups and order flow both increased drastically from day one. We didn’t have more visitors than we normally did (at first), but that just goes to show how many potential customers may be dropping by the wayside if you don’t provide a way for visitors to sample what you have to offer.

Aside from the increased order flow, a positive side effect of the trial is that our support now has to deal with much fewer questions about specific features from prospective customers, since those who are interested can easily see for themselves. Sure, you have more users to deal with, but providing your service is not overly complicated (if so, then perhaps that is something you should look into, but more on that some other time) the support load is more than worth the effort.

Yes, all the key points I’ve listed are pretty much based on common sense, but it is surprising to see how often one or more of these items are ignored. Most often you should just look to yourself. How do you want to be treated? How would you react? Again, common sense, but sometimes in our rush to innovate and therefore often complicate, it’s hard to remember the simple things.

I would strongly urge all web apps to offer a full-featured trial option following the points outlined above. If you really believe in your product, that is the right thing to do, and you should end up getting a lot of new customers who may never have discovered you otherwise.

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. You can download it here.

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!

Research?

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.