How 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.

Harvest pricing

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.

Dropsend pricing

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.

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from HTML, CSS or WordPress.

Start Learning

Comments

31 comments on “How to Price your Web App

  1. Great article Paul. I will definetly use some of these techniques in our pricing strategy. Our challenge is figuring out a way to lower the barrier to entry for our clients. I would really like to further discuss our company and pricing strategy with you sometime.ThanksDanny

  2. Great article Paul. I will definetly use some of these techniques in our pricing strategy. Our challenge is figuring out a way to lower the barrier to entry for our clients. I would really like to further discuss our company and pricing strategy with you sometime.

    Thanks

    Danny

  3. Great article! We needed some guidance on pricing our products on Flabell.com – as our main competitor, FlashDen has lower prices, but much worse products.

    We know now that we have to price them at a higher value than they do. I hope this will work, as we give away free products so that people can see our quality stands in the crowd! :)

  4. Cheer for the article however there were a few things you could have mentioned such as the costs per transactions involved in billing yearly monthly or weekly eg using paypal for 10 3.50 transactions or one 35 dollar transaction and doing cost/savings comparison.

    Vboy thnx you

  5. I used Flat Rate Processing. no bs. I went through 2 or 3 other companies, I felt bs'd. They're good guys and have a good concept. they're website is http://www.flatrateprocessing.com <I think, it might have changed, but I'm not sure>. I had heartland, but I got jipped on the transaction fee and the batch header, so I'd definitely say stay away from heartland and mercury payment systems.

  6. I used Flat Rate Processing. no bs. I went through 2 or 3 other companies, I felt bs'd. They're good guys and have a good concept. they're website is http://www.flatrateprocessing.com <I think, it might have changed, but I'm not sure>. I had heartland, but I got jipped on the transaction fee and the batch header, so I'd definitely say stay away from heartland and mercury payment systems.

  7. Pingback: 9 Must Read Sources On Pricing Your App | Fuel Your Apps

  8. Great article Paul. I will definetly use some of these techniques in our pricing strategy. Our challenge is figuring out a way to lower the barrier to entry for our clients. I would really like to further discuss our company and pricing strategy with you sometime.

  9. Thanks Paul! It’s a really useful article. The one thing that we also debate a lot on is web design and development pricing. Maybe you can do an article on that? :)

  10. Pingback: Payment options for web apps - [codepotato]

  11. Pingback: Craft An Irresistible Price By Focusing On Your Users - Smashing Magazine

  12. Pingback: How to Price your Web App | Treehouse BlogTreehouse Blog | VitaminPrice.com