Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Pricing software

time to read 7 min | 1367 words

It seems that people make some rather interesting assumptions regarding software pricing. When talking about commercial products, there is a wide variety of strategies that you might want to push, depending on what exactly you are trying to achieve.

You may be trying to have a loss leader product, gain reputation or entry to a new market, in which case your goals are skewed toward optimizing other things. What I want to talk about today is pricing software with regards to maximizing profits.

Probably the first thing that you need to do consider the base price of the product. That is important for several levels. For the obvious reason that this is what you will make out of it, but also because the way you price your product impacts its Perception of Value.

If you try to sell your product at a significant cost below what the market expect it to be, the perception is that it is crap, and you are trying to get rid of it.

Another issue that you have to face is that it is very hard to change the base price once you settled on it. It is fairly obvious why you have a hard time jacking the price upward, but pushing the price down is also something to approach with trepidation. It has a very negative impact on the product image. Now, you can effectively price it at a lower rate very easily, but doing things like offers, discounts, etc. Those do not affect the base price and so generally do not affect how the product is perceived.

And just as bad as with setting the price significantly below market expectations, setting the price significantly higher than market expectations. The problem here is that you come out as a loony with delusions of grandeur. Even if your product is wonderful, and even if it will return its investment in a single week, pricing it too high generate a  strong rejection reaction. It also means that you need to actively combat that perception, and that takes a lot of time & effort.

Finally, in the range between too little and too much, you have a wide room to play. And that is where the usual supply & demand metrics come into play. Since supply isn’t a problem with software, what we are talking about is demand vs. price. Everyone in imageeconomics is familiar with the graph, I assume.

As price goes up, demands goes down, and vice versa. So the question is what is the optimum price point that would generate the most revenue. Here are some numbers, showing the probable correlation between price and sales.

Price Users $
$ 2,000.00 1.00 $ 2,000.00
$ 1,000.00 1.00 $ 1,000.00
$ 200.00 100.00 $ 20,000.00
$ 100.00 200.00 $ 20,000.00
$ 10.00 5000.00 $ 50,000.00

It might be easier to look at in its graphical form to the right.

You can see that when the price point is too high, very few people will buy it, if at all. When the price point is in the range that the market expects, we make some money, drastically more than we would when the price was above market expectations.

However, if we set the price way down, we get a lot more users, and a lot more money pouring in. We will ignore the question of damage to the reputation for now.

This seems to indicate that by lowering the price we can make a lot more money, right? Except that it isn’t really the case. Let us see why.

1 in 10 users has a question, requires support, etc. Let us say that each question cost 100$, and now let us look at the numbers.

Price Users Calls Support Cost Income Revenue
$ 2,000.00 1.00 0.00 $ - $ 2,000.00 $ 2,000.00
$ 1,000.00 1.00 0.00 $ - $ 1,000.00 $ 1,000.00
$ 200.00 100.00 10.00 $ 1,000.00 $ 20,000.00 $ 19,000.00
$ 100.00 200.00 20.00 $ 2,000.00 $ 20,000.00 $ 18,000.00
$ 10.00 5000.00 500.00 $ 50,000.00 $ 50,000.00 $ -

And that tells us a very different story indeed. The end goal is increasing profit, not just the amount of money coming in, after all.

Oh, and a final thought, the following coupon code EXR-45K2D462FD is my pricing experiment, it allows the first 10 users to buy NH Prof, L2S Prof or EF Prof at a 50% discount.

Since all the coupon codes run out in a short order, I am going to continue the experiment, this coupon code ER2-45K2D462FJ will give the first 25 users to buy NH Prof, L2S Prof or EF Prof at a 25% discount.



I think you mean profit? Not revenue.

Ayende Rahien


Yes, thanks for noticing!

Frans Bouma

Without deep market research on price and what the perception is of your target audience when they see a price X or Y, it's impossible to say what the price should be. Your graphs look nice, but they just show what a list of numbers will look like graphically, they have little value for an ISV looking for a price for their product, as that's really hard to determine: you've to do research among your own target audience.

It's a big topic, price elasticity and product pricing in general, so big so that it's really hard to come up with any advice in that area in a couple of posts, although it's good that you at least try so people get aware of the fact that there's even such a thing as price elasticity.

Things you ignored (understandably as it's a big topic) are for example the perception of quality related to a price (A product costing 10$ can't be something very valuable, yet a product costing 1000$ better be good) and the continuation of the product in the long run. For example, if you have 200 customers after a year or so, is that customer base enough for continuation of the company and the product? They've purchased an initial version, but will they pay you again for a follow up product? If that's around 30% (random number) for example, you better try to increase your installed base. This is the typical approach japanese car makers took in the 70-ies when they flooded the market with high quality low priced products.

Gianluca gravina

Only one point that has some relevant to the overall, well done, discussion on software pricing, we can't assume that a support call for a 10$ product is equivalent to the 1000$ product, we are looking at that everyday with some buggy paid softwares for the iphone, how many time i heard to "what do u want for something paid 1$".

Try to consider also this point, mixing with reputational effecr due to price, and add also the reputational effevt due to the people who stands behind the product.

To be honest, ayende, if u place your profilers at somethibg like 10$ i think many people will buy it, even if not tied professionally to let'say nh, with an higher price i will wait that my comapny will buy me a license!

Just my consideration ayende!

Demis Bellot

Cool, well it looks like you've done your research and are well versed on the fundamentals of software pricing but I still think your making a big guess with your base price. I think what you'll find is that there is a bell curve on price and affordability and if you price at the 'sweet spot' you will get heavily skewed sales as you've just entered everyone's affordability range. i.e. Instead of the majority of people thinking 'it costs too much I'm not going to buy it', they'll be thinking 'the product is affordable and worth the cost'.

My prediction based on a potential 'developer market' for product 100,000*:

$1,000 => 10 = $10,000

$500 => 100 = $50,000

$250 => 1000 = $250,000

$150 => 5000 = $750,000 (The sweet spot in this case)

$50 => 10000 = $500,000

So in my prediction I believe that $150 is the 'sweet spot' where you will maximize revenue/profits. Now the 'sweet spot' i.e. affordability will be different for each market i.e. 'personal developer licence' vs 'enterprise licence' which is why I believe you should structure your pricing accordingly to these markets to maximize revenue/profits.

  • Now the above just a complete guess on my part as well, round numbers used to illustrate concept.
Ayende Rahien


You don't need to investigate too deeply to understand what are the other players in the market.

Take databases as a good example, you can either price it free, or several grands. Pricing a DB at a 100$ per machine is going to get a lot of raised eyebrows.

For example, I consider the profiler to be a dev productivity tool, so I am looked at things like R#, SQL Comparer, TestDriven, etc.

That gave me an idea about the range of prices where it would be acceptable to do so.

You are correct about quality & pricing tie in, though, and that is something else that is tied to the perception of quality.

The problem with upgrades in software is that it doesn't really decay, so you really got to add new compelling features to move onward.

Ayende Rahien


That is why I am running the pricing experiment :-)

Hyppo Calippo

Ayende, I wanted to "participate" the experiment, but the coupon code seems to be expired...are 10 new users already in?!

Ayende Rahien

That seems to be the case, yes.

Ayende Rahien

Hm, correction, someone used the coupon code in a lot of failed orders.

I reset the failed orders, you can try now.

Gary McAllister

Surely if a software product is good, of high quality and the licensing, documentation is right you can balance/lower the cost (and ultimately make more money). Obviously up-front investment costs more as the aforementioned things require work...

I would expect the cost of supporting software of the manitute you supply would require less support due to quality :-)

Obviously there are licensing options which don't add support and therefore the user accepts the risk. Does this mean you'll drop the price by $100 :-)

I work in an organisation which would love access to your tools but as a government funded sector we cannot afford pen and paper, let alone $200 per head on profiling software. I am not bitter, just jealous.

Patrick Smacchia

Let us say that each question cost 100$

This is not my experience, answering properly a support question takes 5 mn to answer and 10 to 30 mn to modify the product embedded documentation (generally a tooltip with an image, but sometime a command must be added or modified) to avoid the question to be asked in the future.

I apply relentlessly this approach and so far it has been successful for years.


Still too expensive for the home tinkerer. Wish you'd come out with that less-than-full-featured version!

Also jealous and not bitter!


I'm not even sure If i should contribute to this post because I feel I'll just end up ruffling someones feathers or be accused of wanting things for free and devaluing something simply because I feel it isn't worth it's current priced based on what you get.

But I want to comment on the support calls. If the documentation for the product is good, then you wont receive many support calls to begin with. If you are receiving support calls for the same questions over and over then your product fails at usability or your documentation is poor.

I don't think that is the case at the moment. The readme supplied with L2SProf provides enough information to setup the profiler and use it.

If you have enough market penetration that people blog about your software, a lot of questions could be answered via google search.

Everyone who reads your articles, at some point has googled for the solution to a problem before even considering going to a partner, vendor or paid support. And have successfully found their answer.


The price also impacts people's expectations for support. For a $2,000 product you expect to get some free support. For a $10 product I'm not sure what the expectation is for free support, but it is definitely less and you could either sell separate support contracts or charge per incident with a $10 price. Do you think that allows you to reduce the price or do you think you just get irritated customers?

Steve Py

I don't think I'd agree with the the price's impact on perception of quality in software. In consumer goods, absolutely, but I think that has more to do with brand recognition than price. People will be willing to pay more for a recognized brand than a cheaper one they probably haven't heard much about.

For instance when I started doing graphical arts as a hobby I went out to buy a professional graphics package. The package was Adobe Photoshop, which at the time was around $360. Then I came across Paint Shop Pro: $75. I checked the features and it had ticks in all the boxes I was looking for. It turned out to be an exceptional product. Maybe it doesn't do 100% of what you can do with Photoshop, but you don't need extra books to figure it out either.

Software's also easy to demo, so regardless of price I don't think anyone would say "that's too cheap, it must be crap" without even bothering to download a demo.

As for support goes: I learned when doing a stint on the MSDN forums that while many people will actively go out on the web and search for the information you need, many simply don't bother and post the same questions that have been asked and answered repeatedly. But these are a minor distraction, a 1 liner with a hyperlink or a "please RTFM." Still, I don't believe support is a 100% drain on profits. Any piece of software can benefit from being improved, potentially generating more positive reviews and more sales. In responding to legitimate support queries it becomes an investment into improving the product. (A new bug that can be fixed, a feature that can be improved, or topic to write an article about.)


No one mentioned Joel Spolsky because he's an idiot. He needs to get off his high horse.

Same with Jeff Atwood. Bloody glorified writer, amateur programmer. Tired of hearing those 2 names.


Of course there's always the question of how many people are in the target market for product X. Sometimes it won't make sense to develop a product since all the price/quantity points that generate a profit have a quantity that is greater than the number of potential users in the target market.


That Spolsky article is one of the reasons you hear his name all the time. I'm hardly a fan, but that article is the dog's.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats