I’ve previously written extensively about taking an analytical approach to the pricing of software products. In this article,  I want to cover specifically the type of products we list on Binpress – libraries, SDKs and other source-code components for various development needs.

Knowing Your Audience

There are many types of software products – games, productivity software, security products and so forth. Libraries, SDKs and other source-code products are generally categorized as developer tools.

Each category of software products appeals to a different audience and serves different needs. Developer tools are aimed, naturally, at developers (or software companies) and are more often than not a type of productivity software -  they help developers achieve more in less time.

Lets examine some common characteristics of software developers:

  • They are usually very technical people. This means that if a cheaper / better / free alternative exist, they are likely aware of it.
  • They know how to build software – which is what you are selling them.
  • They are usually too optimistic about time estimates. That means they might be undervaluing your product.
  • They are a niche audience compared to other software categories. Software developers are not a large portion of the general population (yet).

Those characteristics makes selling developer tools tough. Because of that, we need to be extra careful with how we price our products.

Impulsive vs. Planned Purchase

Buying a source-code library is very different than buying a game on the iPhone. Developers usually make the decision to purchase a source-code product after searching for free (open-source) solutions first and looking over all the alternatives (competing products).

This means that when making the decision to pay for a source-code product, the developer is already pretty committed to that decision. This is in contrast to a buying decision on the appstore where you might pick up a game that looks cool in the screenshots for 0.99$.

The reason I’m emphasizing this difference is that too often I’ve seen mobile app developers try to price their source-code products the same as they do their mobile applications, without considering the completely different audiences. Buying a source-code product is not an impulsive purchase, and the biggest decision for a prospective buyer is whether to give his credit-card details online. Once that decision is made, the actual costs become less significant.

Size of Market

I’ve mentioned that developers are a niche market. It is a large enough market that general purpose tools (IDEs for example) have a large audience, but depending on the purpose of your product, your target audience is probably significantly smaller.

If your product solves a specific problem in a specific type of application for a specific environment – that narrows down your target audience significantly.

Source-code products usually cannot hope to achieve the sort of mass-popularity that other types of software are able to reach. Considering that, we need to value each sale higher, in order to be able to generate significant revenue.

The maximum revenue we can hope to generate from our product is the price we set times the size of the market. For large markets we can always count on more customers, but for small markets we are putting a cap on the amount of revenue we generate by pricing our products too low.

Different audience types and needs

A single developer has different needs than a software company. Someone who manages a single-site has different needs than someone who manages a network of 30 sites.

To accommodate different audiences, we should present multiple pricing and licensing options that appeal to each. In our previous article, we called this tiered pricing and it serves multiple purposes:

  • It creates the appearance of better value for the lower tier pricing.
  • It creates the opportunity for a larger sale with the upper tier pricing. You’d be surprised how often larger companies or people with a larger budget will go for the “Premium” option, just because it’s there (they want the best version).
  • It allows you to handle different licensing requirements. This is important since specific licensing details can be a deal-breaker.

This is an advice we repeat in many places on our service, and it greatly affected the licensing options we provide in the “Licensing / Pricing” step of our component creation process (must be logged-in to view).

Price Conveys Value

In the previous article on this topic, I’ve discussed the perceived value of your product – with price being a big factor. When you price a source-code product that claims to save hundreds of hours of development time the same as a meal at McDonald’s – you are sending the wrong message to would-be customers. You are making them ask the wrong questions – why is it so cheap? is the quality of code low? does it have many bugs or is not supported?

The tactic of pricing low to sell more can actually backfire and decrease sales. On the other hand, pricing a product at a healthy price conveys significant value and makes the product appear move valuable.

Software development is expensive – when we save development time we also save development costs. We should aim to keep a healthy ratio between the amount of development time saved and the price of the product. Too large or too small ratios will result in a price that does not convey the value of the product properly and in reduced sales.

Finding the Sweet Spot

In the previous article we’ve discussed the demand curve and that our goal is to find the pricing point that covers the most area and generates the most revenue.

Our goal is still the same – to find the highest price that generates the most sales. It takes some practice to get good at it, but you can get to a good starting point by considering all the factors we’ve covered:

  • Buying a source-code product is not an impulsive purchase.
  • Price should convey the value of the product and be proportional to the development time it saves.
  • Price should take into account competing products.
  • The market size / scope of the solution the product offers should be taken into account as well.
  • Different pricing for different audience types.

Improving by collecting data and iterating

Once you settle on a starting point you feel comfortable with considering all those factors, you should start gathering data by measuring how it affects conversion rates (the amount of sales per visitor).

You can try and test both lower and higher prices, and see if it affects conversion. Note that when you raise prices, if conversion stays the same – you have increased your total revenue. Make sure to allow for enough data to accumulate before changing prices – and not change other parameters as well at the same time (product features, marketing content) to get reliable results.

Learning by Example

We’ve previously published a case study with one of our publishers and mentioned the pricing experiment he ran with his component with good results. We intend to publish more case studies such as this in the future to illustrate the effect pricing has on the success of source-code products.

If you have specific examples you want to read about, let us know in the comments!

Posted in Pricing