Sunday, March 1, 2020

Finding the Price

Let’s dive once more into the licensing breach! Here’s the background:

What’s not covered? Well, when I wrote this post about evaluating a side business, it came close to the process for defining the price of a cost-plus service or product. That’s not a particularly hard task in theory:

  1. Find the cost
  2. Add a margin
  3. Adjust as needed per your favorite Economics 101 textbook

Of course, this simple approach will provoke sniffs of disdain in most software circles, where the dream is to write code once and deliver it forever. In software, the task is supposed to go like this:

  1. Find the value
  2. Subtract a discount
  3. Adjust as needed per textbook

If your software solves a million dollar a year problem and costs you $5,000 to write, you’ve got a lot of room to negotiate a price in.

Running a successful enterprise of course requires you to think about both approaches, because if you find yourself negotiating prices that are below your cost, that won’t end well.

Furthermore, the Platonic ideal of writing software once and never touching it again is pretty rare; most complex software needs to be continually maintained in order to fix bugs and keep up with changing fashions. This makes cost a little more challenging to determine, as it’s an ongoing function of R&D team size (not to mention support functions, cost of sales, &c).

Even worse, Software as a Service and other, simpler forms of term licensing require you to predict costs and values into the future and spread them out, probably in a way that front-loads your costs and back-loads your profits. In some ways this matches the realities of software development more accurately since it allows for ongoing cost and value increases, but it can also set off a treadmill of expectation increases. That is to say, a SaaS which does not continually improve will not compare well with one that gets gradually more feature-rich and nicer to use. As discussed before you could also use bands or freemium models to disproportionately allocate costs and profits across different classes of users. Or you could aggregate one class of customers into a service that you sell to another class of customers, if you’re feeling particularly Silicon Valley. All of these approaches are just abstractions over the core problem of pulling in more money than you pay out, don’t let them distract you.

So, just like license models, price is deceptively simple:

  1. More expensive than your costs
  2. Less expensive than non-consumption
  3. If you’re going to spread the cost out, make sure that you don’t drop average prices below average costs. 

Glad I could help.