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.
Excellent article. I’ve been planning a web application and this has been an area I’ve been struggling with.
[…] In questo articolo di Vitamin, vengono spiegati i principi basilari da utilizzare per decidere quali prezzi, quante fasce di prezzo e quale features offrire un’applicazione web. […]
Great article. I have a couple of questions…
You hinted that you’ve raised your pricing since you originally launched. How did you communicate this price increase to established customers, and how did they take it?
David: Thanks, I’m really glad you found it helpful.
James: Yes, we did increase the price. Our price increase coincided with switching from US Dollars to Euro, which I expect obfuscated it a little (though that wasn’t why we changed the currency). We didn’t change the price for existing customers, however, so there wasn’t any kind of backlash. The change in pricing also coincided with our re-launch of the product, which included many new features, and therefore should seem justified in the eyes of any potential customers who observed the re-launch.
The other advantage of doing a yearly cost rather than a monthly one is that you then only pay one transaction fee to your Payment Services Provider, rather than 12 if you bill monthly.
Great information. I found it easy to digest, but very helpful.
Best of luck with th site,
Mike
You’ve offered up some great pricing strategies regarding web applications. It’s interesting that there’s not that much study on market segmentation and pricing when it comes to web-based services. I’m thinking economics PhD candidates would be drooling over a thesis like this.
I feel things get a bit more complicated when considering your competition as well. For example you noted the competitor Browsercam. Regarding your price plans, now what if they decide to add SSL to their freelance package to gain ground? Now your forced with a decision. Do I lose freelance customers to them that want this feature at the lower cost, or do I lose high end customers that may now be able to downgrade their plan to the less costly one. The tough part in pricing often is compromising between what you think people may pay for the product and what the market dictates the price should be. I’d be interested in your experiences with this as well.
Interesting and nicely articulated.
The “Price Points” section reminded me a lot of GoDaddy. They seem to have that stuff down very well.
Great article. One question is how can monthly payments be taken online? I know PayPal offers some services. Are there any others that you recommend?
Great article… I’m also interested in what services you recommend for taking online payments?
Good article. Especially about pricing to low. A business consult once said to me, if you price your product lower that you competition, you will be perceived as being a low class provider. Where as, if you are in the main stream or slightly higher, the thought is that you are providing a competitive or better product.
Great article, but here’s a question for you. It seems you based your pricing plan on competition that is currently out there. We recently launched a new site that has no competition as of yet, in that it’s completly unique. We too have had countless hours of discussion trying to come up with not only the correct pricing plan, but also the correct way to launch. There are a ton of books out there to tell you how to build a site, but not any on how to launch! Any thoughts?
Keith, there are services like 2checkout.com and Worldpay.com. I’ve used 2checkout on a couple projects and they seem to work well. If you do a google search for online merchant services you should find something that fits.
Paul, well written article and excellent reasoning. It may not give an exact formula for pricing but it adds great insight and perspective, thanks.
Paul
A very interesting article. You’ve basically voiced a lot of the stuff we’ve been talking about internally for the last couple of months as we are in the rampup stage for a new set of services.
Your point on the number of plans is very true. Users / clients get very confused if they are offered too many options. Some of the more successful businesses only offer 1 or 2!
As for the payment processing - unless you’re doing large volumes processing small monthly payments can get very expensive regardless of your chosen processor - annual fees work out a lot cheaper. Obviously your choices are going to be affected by how long you’ve been in business etc., Accepting AMEX for example is more expensive if you’re based in Ireland.
Michele
[…] Sep 12th, 2007 by Brad By Paul Farnell […]
[…] read more | digg story Fling it to: […]
[…] Vitamin Features » How to price your web application In the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. (tags: application applications business entrepreneur pricing startup web2.0 entrepreneurship web best-practices) […]
[…] Vitamin Features » How to price your web application “Pricing is always somewhat of a black art” - ACK (tags: web business pricing) […]
[…] Vitamin Features » How to price your web application Bookmark to: […]
[…] How to price your web application (tags: web web2.0) […]
I don’t think my last post made it (dam Internet).
I was just going to ask about “add ons” for accounts.
Lets say the difference between the current/next account is $30 and the client only wants to add one more user to their account, shouldn’t they have some flexibility (eg pay an extra $5 per month for an additional user). I don’t have my figures right but I hope i’ve made my point clear.
[…] http://www.thinkvitamin.com/features/webapps/how-to-price-your-web-application […]
Interesting post. Thought you might appreciate this more in depth post - http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html
Darryl
Thanks everyone for the great feedback!
DSB: With regard to the market dictating the price, there are services such as iCapture and BrowserShots. They’re free, and they provide a similar service to ours. But we’re competing on more than simply features, we’re trying to craft a more enjoyable experience through the design of our application. That, we have found, is something people are willing to pay for - especially in the design market.
Keith, Lydon, Sheridon: We use PayPal Website Payments Pro to take our subscription payments. We used to use 2checkout, but with them your customers must use the 2CO site to place their order, so we couldn’t control the entire signup experience. PayPal has worked well for us so far. We’re going to post a write up of how we did it, from a technical angle, on the Litmus blog very soon.
Tim: That’s a difficult situation, I agree. I’d go back to my point about pricing by value added. Try to guesstimate how much value your product adds; that may give you a starting point. What’s your customers’ alternative to using your product? How much pain are they currently feeling, that your product would remove? I think it’s also useful simply to imagine how much you would pay for a similar service. Of course, you may have already covered all these points yourselves :)
Drew: That’s a reasonable approach, but one downside is that you complicate things. For us, you’re likely either a freelancer (one person) or a team/agency (multiple people). If you’re working in a situation where there are multiple designers, chances are you’re either at an agency or working on a pretty large project. In either of those cases, you can afford a Team plan. Again, think of Basecamp. If you need 16 projects, you can’t add one more to the $24/month plan, you simply have to upgrade to the $49/month plan. I think that’s a straightforward and fair approach.
[…] How to price your Web application. […]
[…] Charging for a service in the “everything should be free” web world can often be a difficult task. Paul Farnell breaks it down and makes it sound sensible in How to Price Your Web Application. 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. […]
[…] Amazon.com Startup Challenge — ваш Ñтартап может получить $100,000 + PR от Amazon еÑли вы иÑпользуете Amazon Web Services […]
[…] How to price your web application. […]
[…] How to price your web application 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 enh (tags: pricing webapp tips thinkvitamin vitamin price litmus) […]
[…] How to price your web application - those stylish Vitamin guys hit us with another quality article. […]
How to price your web application…
Pricing is always somewhat of a black art, and a subject about which there is precious little written with regard to web applications. Here I’ll discuss some common factors and hopefully help spark some ideas which can help you decide upon the price of…
If anyone is interested in following my ongoing thoughts on web app pricing, I’m starting a blog about it called On Pricing.
[…] http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html http://www.thinkvitamin.com/features/webapps/how-to-price-your-web-application http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html - Definitely have to read this more […]
i’d have the basic package as free then offer extra features for a small fee, rolling into the pro-i-can-run-my-business-with-this for a bit more.
be human and nice to your potential friends & customers.
[…] How to Price Your Web Application - A great overview of how to price your new web app. Gives plenty examples of successful web applications and at what point can charging for an application be successful. […]
[…] “on pricing” ist der Blog von Paul Farnell (litmus), der sich nun nebenher auch mit Preisfindung und Preismodellen für WebApps beschäftigt (noch ganz neu und daher noch nicht viel Inhalt). Das dürfte für viele interessant sein. Auch meine Wenigkeit beschäftigt sich gerade für mein “SAY-HO!”-Projekt stark mit Preisfindung, und ich kann versichern, dass diese Thematik nicht gerade trivial ist. Aufgefallen ist Paul Farnell in Verbindung mit dem Preisfindungsthema durch seinen Beitrag in Vitamin. […]
Price points can be a hard thing to come up with for a site and they are hard to change later (just ask apple about their iphone).
Paul, great article. What are your views on any alternatives to a subscription model that involves regular billing cycles? What about a model where users get charged a one-off amount to unlock a premium feature or set of features?
[…] How to price your web application @Vitamin […]
[…] Link to Vitamin Features » How to price your web application Social Networks: […]
Hey Paul, nice article!
This is something we struggle with monthly at http://www.copperproject.com especially as we offer both a hosted component and a licensed installable option (web-based project management software).
However in the last three years we’ve conducted an annual survey that asks the very question, “what would you pay for our products” along with a matrix of our segments (Standard, Corporate, Enterprise). The benefit of seeing the varying qualitative answers is immeasurable, but by reviewing the distribution of the answers we usually hit on the sweet spot.
There are always extreme end of the spectrums, such as those who think we’re mad for charging anything at all (to which I’d be happy to introduce these guys to my bank manager), and those in the Enterprise sector who feel we aren’t charging enough. However the distributed curve of responses gives really good insight.
For example, our licensed Corporate edition was $999, but in a recent update (which placed Copper well ahead of our competitors in terms of functionality) we increased the price to $1499. Our 2007 survey (still underway) however has shown an overwhelming response of $1299 being the ideal price point, so we’ll likely review this pricing at completion of the survey and pickup those customers who just wouldn’t go the extra $200.
The responses regarding the pricing on our hosted accounts ($29,$99,$199) were also interesting, and coupled with our other survey questions we were also able to glean whether an additional product segment was required. It looks like there is requirement for a new product, and in our case we might move to a four-tier offering (possibly a free solution, but we’re just not sure whether we want to go down that path just yet.)
Finally, historically we’ve segmented on user numbers as well as product features, which we’ve found to be a necessary evil, but this does create a little confusion amongst users (e.g. I want the Corporate edition for the features but I don’t need 50 users), we’ll try and combat that in future by moving to a single restriction style (users/projects/features, not sure yet).
Anyway, hope this provides some insight as to how we’re tying the black art to some quantitative analysis.
Thanks again!
Great insight. Researchers have determined that when faced with too many choices, people will leave without choosing anything. Three is a good number of choices.
Pricing web applications and services…
One of the toughest marketing issues for any business, let alone a company providing web services, is pricing. I recently found a link on Brian Oberkirch’s blog to On Pricing, a site describing itself as “an ongoing discussion of web app pr…
[…] Further to my past quest on how to price web software, someone recently send me this link, which is extremely helpful: how to price web applications. This post makes a good job at describing the general best practices of monthly pricing for web-based software, such as : […]
[…] On Pricing is a micro-blogging site (using Tumblr) to grab information about pricing web apps from around the blogosphere. It’s run by Paul Farnell, founder of Litmus, who wrote a great article on pricing web apps awhile ago. […]
[…] How to price your web application Wie bestimmt man als Entwickler optimale Preise für seine Web-Applikationen? Der Beitrag beschreibt einschlägige Methoden und Prinzipien, mit denen unterschiedliche Zielgruppen angesprochen werden können. Insbesondere ist es wichtig, verschiedene "price plans" anzubieten und das Einkommen der Zielgruppe genau im Augenblick zu behalten. […]
[…] How to price your web application Wie bestimmt man als Entwickler optimale Preise für seine Web-Applikationen? Der Beitrag beschreibt einschlägige Methoden und Prinzipien, mit denen unterschiedliche Zielgruppen angesprochen werden können. Insbesondere ist es wichtig, verschiedene "price plans" anzubieten und das Einkommen der Zielgruppe genau im Augenblick zu behalten. […]
[…] How to price your web applicationIn the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. […]
[…] How to price your web applicationIn the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. […]
[…] كي٠تسّعر برنامج : هل أنت مطور ويب كي٠تسعّر برنامجك . […]
[…] Vitamin Features » How to price your web application (tags: business pricing startup web2.0 entrepreneurship webapps marketing) […]
[…] How to price your web applicationIn the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. […]
[…] read more | digg story […]
[…] How to price your web application Un article qui dresse quelques pistes de réflexion pour s’y retrouver lorsqu’il faut mettre un prix sur un service web (surtout dans le cadre d’abonnements premium). […]
[…] Read here. […]
I think the most important rule with pricing anything that you sell as a business is sell it for more than it cost you from David A. Eichenbaum’s book The Business Rules.
Regardless of what business your are in this is rule number one when pricing your application. Another rule is to know how much it cost you :)
[…] Vitamin Features » How to price your web application […]
[…] Jak na cenovou politiku pro web aplikaci […]
[…] How to price your web application In the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. […]
[…] How to price your web application In the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you here. […]
[…] How to price your web application […]
[…] The author is Paul Farnell, the founder of Litmus, and a recent contributor to Vitamin on how to price your web application. […]
[…] In the world of free, pricing isn’t given much attention. But if you’re looking for a real, sustainable business, it’s unavoidable. Paul Farnell’s gone through it all with his app Litmus and breaks it down for you in Vitamin - How to price your web application. […]
La ce pret iti evaluezi site-ul ?…
Cateva idei care te vor ajuta sa-ti evaluezi corect pretul site-ului….
[…] […]
[…] You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your ownsite. […]