Pricing your product
While writing a quick comment on Paul Boag’s recent post I thought that the issue of pricing online products, and specifically how we approached setting a price for Perch, might be of interest to anyone else considering how to charge for their work.
Perch is a content management system developed and sold by my company, edgeofmyseat.com. It is a self-hosted CMS, so after buying a license for £35 (+ VAT if in the UK/EU) customers download the code and install it on their own server. The payment is a one-off with no monthly charges and includes support, updates to future dot releases of that version, and a growing number of free add-ons available from the site.
Why not offer the product for free and charge for support and/or plugins?
Every so often we encounter someone who is outraged that we charge money for a Perch license, astounded that we would like to earn money for our work. We could have released Perch as a free product, but unless it is making us money we wouldn’t be able to justify company time spent developing and supporting it.
Obviously there are products that have done very well as open source, free to download products but these companies have to make money somehow. A common way is to charge for support, however we think that the charging for support model is a really bad one – for the customer. A Perch license includes support, if you take a quick look at our support area you will see that the support offered quite frequently goes way above and beyond just basic installation help. It is in our interests as a business to try and “design out” of Perch, and the Perch documentation, support requests. If we can add some additional help or refine a confusing interface and prevent a bunch of support requests we make each license more profitable. If we make our money by selling support then it is actually in our interests as a company for the product to need support! We would much rather spend our time writing code and help resources to make customer’s lives easier – than supporting people who are frustrated – so the pay for support model was always a non-starter for us.
There are also products on the market that have a free basic, core product but then you pay for plugins to make the product more fully featured. We didn’t want to go down this route for a few reasons. Firstly, we want to make the core product as fully-featured as makes sense for a “light” CMS. We didn’t want to be making decisions about chunks of functionality – should x be part of core or should people pay for it? We want to develop the product in terms of what makes sense for the product, not with one eye on how we monetize features. Secondly, we wanted it to be clear what people pay when they decide to use Perch for a site. You buy a license and that is it, you can then download our add-ons as and when you need them without paying additional charges. If we did things the other way round and offered the core free then charged for add-ons we would be having to say to people in support that they needed to buy X, Y and Z to do what they wanted and the cost to the customer starts to creep up, and isn’t clear from the outset.
Why not offer a multi-site license?
The most common request we get is for a multi-site license, “buy once, install as many times as you like”. We didn’t go down this route because firstly it would make the base price far more expensive. Everyone buying it would be buying the ability to install it many times – what if you only have one site to use it on, or don’t know how you and your clients will get on with it? In addition, we feel that this model is again bad for the customer. Once a customer has bought a license, we wouldn’t see any more money from them. We might need to support them through every install they do, without any additional license fees. If a customer pays a small amount each time they buy a license, the incentive is there for us to keep that customer happy through each install in the hope that they will come back to buy a license next time they have a site to do – rather than going to our competition.
There is a final reason why we don’t like the multi-site idea and that is that the license then follows the developer. As most Perch customers are design agencies, buying a license on behalf of their client, the license per site model works very well. If the end client wants to move their site to another agency they are able to move their license as well – it isn’t tied to a multi-site license held by the agency. So it ties in nicely with the transparent way we like to work at edgeofmyseat.com – essentially we’re licensing Perch in the way we like to deal with licensed software for our clients.
Why not offer a free version for personal use?
Perch has an online demo but no free personal, non-profit or trial version. This was a deliberate decision on our part and in addition to the usual concerns in terms of protecting our intellectual property it really comes down to our aim to offer exceptional support to all of our customers. If you have a tier of free users of your software or service, the paying users are essentially paying for their support – and in the case of hosted products their bandwidth and resource usage. To offer any kind of free version would mean making paid users pay more, in order that we could afford the time to support all customers.
Almost two years on we haven’t changed the pricing model that we set out with, as we still feel it was the best decision for the product. To some degree, having never launched a product before, some of those decisions were based on what felt right at the time, and the way that we like to work with clients in the service side of our business. It has been nice to see those initial hunches pay off so I thought that discussing some of the thinking behind our choices might be of interest to other people making these decisions. As always, I’d love to hear your comments on pricing models for downloadable software and software as a service. What works for you as a customer, or as a seller?