Software Pricing Models

It has been a real struggle to come up with successful software pricing models. We’ve found some patterns and concepts that just conflict in real life, making balancing needs of clients with demands on developers very difficult.

We have a piece of software, which provides advanced automation for webmasters. Now, this software saves a webmaster anywhere from 30 minutes to 4 hours PER use. That is still time they can charge for in many cases, but they don’t have to do the grunt work, the software simply does it. It was never meant for startups – startups really don’t NEED this automation. It is a tight niche software – only works for webmasters who use two specific platforms. So the target market will never be that big.

So, we have two kinds of customers – those who ask us why it is so cheap, and are suspicious because it is, and those who keep asking us why it has to cost so much. It is priced at $395 for the full version, but we usually have discounts on that (big ones). The Light version is $99. Interestingly enough, most complaints AREN’T about the price of the full version. They are about the price of the LIGHT version! We’ve also had prospects email us and ask us whether we would sell them the Full version for less than the price of Lighter. We had to say no, because we simply cannot support it for that.

In many instances, you can increase revenues on software by making up for it in volume. With this one, we can’t do that, for two significant reasons:

• The market isn’t large enough. It is a tight niche market, one that is difficult to reach through marketing, and the customer base will never be that large. So there just aren’t enough prospective customers to get high volume.
• The support is fairly intensive. It ranges from conflicts with server settings, to user typos, to coder typos (hey, they happen), to Failure to Read the Manual. It averages about 1-2 hours per sale. With that kind of support need, we just CAN’T drop the price down and hope to make money by doing so.

So the next suggestion was to drop the price and offer it with NO support, and then charge for support. Hmmm. That’s fine, except you STILL have to support it when it is a typo in the manual or a bug in the code, or a server conflict, because those are things WE are responsible for fixing. But we never know until we get into it which it is (often it is a combination of things, our responsibility and client responsibility). So you can’t just say “no support”, you still have to support it. And since clients can’t draw the line, and we don’t know until we look which type of problem it is, there is no effective way to manage a paid support system and still get paid. Too complicated.

The last one was that we go to a subscription model. Ok, we are going in that direction, but it is, in some ways, counterproductive. In order to implement a subscription model, we need additional programming to track and activate and deactivate the software for paid or overdue accounts. That increases our development and maintenance costs. This means that people are not going to get this for what they want to pay for it – it will still cost them more per month than the cheap ones want to pay.

I don’t feel obligated to please everyone. Basically, I feel that this software is best for established webmasters, NOT for startups. That is who our pricing is for. If they develop it for themselves, they will find they are investing thousands of dollars into coding. We ask them for about a tenth what they’d spend, and they get it now, instead of also having to spend a year developing and testing it.

No one else is offering anything like it, because people who do develop software like it either keep it in house, or they burn out in the development process and do not want to have to support it. Most don’t even finish it if they start coding it, because it is much more difficult than it seems.

It is simple to look at a piece of software from the outside and say, “this should not be so expensive!”. And it is easy to make the developer the bad guy when something doesn’t work as expected for our particular use. But software development is HARD, and supporting it can completely eat up every single penny of profit. So when faced with constant complaints about cost, and a huge drain on resources from support, many companies drop support to nothing, and lower the cost of the software. Their reputation drops too – but people don’t complain quite so loudly because they didn’t lose as much. But that isn’t who we want to be.

I’ve considered just raising the price to $500 and letting it go. Let those who are ready for it pay for it, give them red carpet treatment, and thumb my nose at the rest. But I’m not sure that is the right course either.

Pricing models are often more complex than outsiders assume they are, and the pricing model chosen for a business has to be right for the complexity of factors in that business specific. It isn’t the only factor in success – it is an important one, but to work, has to be combined with other well balanced factors.

We’re continuing to work with the variables to reach that balance.