free html hit counter
Posted on: Friday, 01 October 2010 by Rajiv Popat

The Microsoft SQL Server 2005 pricing model is transparent, online and in your face for you to decide if the product fits your pockets.

MySQL on the other hand seems like a "call us to find the price" operation when you first Google for its pricing.

The kind I prefer referring to as the Mafia Ransom Pricing Model.

Even though MySQL is in reality not a "call us for pricing" operation I cringe every time I see marketing guys show their famous "call us for pricing" move.

Pricing is hard. Pricing takes a lot of experimenting. You can never price your product to please everyone.

But that does not mean that you run away from the problem all together, hoping that your potential customers will call you every time they want to know the price of your product and then they will spend countless hours haggling with you.

The "call us for pricing" approach tells your customers that you have no clue about what your product should be priced at.  It also tells the customers that you are going to charge each customer differently not on the value your product provides but on how much the customer is willing to pay or a host of bizarre factors.

Consider this line on MySQL pricing page for instance:

With MySQL Enterprise Unlimited, companies with up to 1000 employees can deploy an unlimited number of MySQL Enterprise Servers, with full 24x7 production support for a fixed price of $40,000. You also get unlimited 24x7 access to MySQL Enterprise Monitor.

It does not take a rocket scientist to catch a bad vibe about the pricing model if you are somewhere in the nine hundred employee ball park and are looking to hire more people. What happens when you cross a thousand employees? You call up folks at MySQL and haggle with them?

Ever wondered what the correlation is between which database your project uses and how many employees your organization has? None.

To understand this concept of "no correlation" between what you charge for your product and what the pricing depends on, lets start by assuming that we had an awesome word processor that you were interested in buying. We started off with the "call us for pricing" tagline on our website. Now lets assume that out of the hundred customers that saw the website and the ninety seven who never came back, you fall in the range of three customers who did.

Let's also assume that you actually picked up the phone and decided to give us a call. On the call, we told you, that what we charge you for the product is going to depend on what kind of documents you choose to write with our word processor.

If you write a blog post that no-one reads, we would give you the word processor for fifteen dollars a license but if you were to do the sales deed of your home on it, the price of the word processor would shoot up to five percent of the deed price.

Picking important factors which have strong concrete correlation to how you price your product is also important. Pricing a database license based on the number of users or processers is perfectly fine but pricing it on the number of employees in my organization is as messed up as pricing a word processor based on what I plan to do with it.

MySQL does seem to have a well defined pricing page too and this post by no means is an attempt to thrash MySQL. The point of this post however is to convey the central idea which is this:

Every time I see a product website with well defined versions and price tags attached to these versions, I make a decision based on if it fits my pockets and needs. Every time I see a "call us for pricing" tag on the pricing page of a product, I cringe. I almost never call. But then again, maybe that is just because I am a geek. Pricing is a hard problem but that does not mean you avoid it. Putting a "call us for pricing" callout on your website is not an answer.

Now go figure out your product plans, prices and publish them on your product website.

I wish you good luck.