LearnHow to Price your Web App

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.

• web app