Broadly, there are three ways to price any subscription software product:
- Consumption Based – where the price charged is based entirely on how much you use, and which features you use.
- Tiered – This is similar to consumption based, but split into coarser tiers such as bronze, silver and gold as you add features and capacity.
- Flat Fee – Where there is essentially a flat fee for using the product with all features and in an unmetered manner.
In the analytics industry where Timeflow is operating, the vast majority of companies use heavily consumption based pricing. You’ll pay per user, per gigabyte ingested, per alert, per agent, or sometimes some arbitary “credit” system.
Consumption based pricing is generally better for the customer. The price you pay is tied to the value you get, and you aren’t paying for capacity or features that you don’t need. It also creates a low cost of entry whilst you start, and the cost only grows as your usage increases and the value becomes proven.
The problem is that the consumption based pricing models can be a bit of a trap due to banana skins such as the following:
- The unit costs look low, but you’ll use a lot of them. For instance, there might be a “per gigabyte” cost for ingestion or a “per agent” cost, but to get any value at all from the system you will realistically ingest a lot of gigabytes or need at least a handful of agents. The cost will therefore be some multiple of that low initial price before you even get started.
- Sometimes, you go in with your eyes open to the above, but the costs grow quickly over time as you have more people using the platform and process more data or connect more servers. Something which seemed small quickly becomes a large uncapped expenditure whilst all the time you are becoming more locked into the platform. At some point, the bill lands on the CFO desk and heads start to roll.
- There are modules or features that you find you need which aren’t included in the base price. Over time, more of these get switched on and costs grow further still.
- You might pay to scale up your environment, but because people forget or you don’t have the processes in place, you never scale down, so your prices only ever go up even though you are paying for an adaptive and elastic service.
- The price quoted for base versions can be underpowered. To run a viable production version of the software you need at least a certain amount of memory, or a certain number of instances to avoid the risk of data loss. (This is one area where vendors are disingenuous, as a datastore configured with terrible performance or at risk of data loss shouldn’t even be in the market.)
- Sometimes, vendors recognise all of the various complexity and try to wrap it all under a “standard consumption unit”. Though well intended, these can be hard and opaque for customers to understand, predict and model, and are usually more expensive than they appear.
This isn’t to say the tools aren’t great and don’t deliver increasing value, but the financial risk and exposure to the customer is real. They will start with something which they think will be small and tactical, but can end up with quite a major expenditure which they are locked into, and need to battle against to keep costs down or potentially migrate away from.
For this reason, here at Timeflow we are generally against consumption based pricing as we do not see it as customer friendly in this particular space. A data platform will of course be bringing in more and more data over time, from more and more sources, so consumption based pricing just doesn’t feel right.
The downside for us is that this does make apples to apples comparisons tricky in pricing conversations. Timeflow have a more transparent but more inclusive pricing model, whereas our competition have a small “per unit” cost which looks more attractive at the outset. However, as soon as you move into production, you will usually find that other products grow in totally uncapped costs, whilst we are relatively fixed (fair usage charges aside.)
We have shared our experiences as we expect to be referring back to it multiple times in the coming months. We would welcome any thoughts or input into this as we try to evolve the ideal pricing model.