Staff+ Engineer in the SaaS World - Pricing and Cost Management

The next topic I’ve decided to tackle as part of our journey through the SaaS world is pricing and cost management.

The cost of the solution being designed is something that should always be on the minds of staff+ engineers, but in the context of a solution delivered using a SaaS business model this topic takes on a special meaning as the architectural and commercial aspects are inextricably linked. In such solutions, COGS are in the same line as typical architectural metrics.

Cost of Goods Sold (COGS)

Cost of Goods Sold (COGS) represents the costs associated with delivering the solution to the customer. These costs include infrastructure, engineering, but also other related costs such as tool licences. This is important because if the solution is sold below its COGS, it’s unprofitable (which may be acceptable for a period of time, but is ultimately unsustainable). As a staff+ engineer, you will be expected to take direct responsibility for at least the infrastructure component of the COGS. This means that you need to be able to measure it.

The challenge of measuring the infrastructure component of the COGS is directly related to where your solution falls on the multitenancy spectrum. It’s easiest at the “share nothing” (fully isolated) end of the spectrum, where you can simply calculate the cost of the infrastructure provisioned for a given tenant. The closer you get to the “share everything” (fully shared) end of the spectrum, the harder it gets. The biggest challenges tend to be around compute or networking. When you’re sharing storage (whether it's block storage, blob storage or databases), you can usually still get separate costs based on metrics provided by the storage service. But the moment you start sharing compute, and by sharing compute I mean deployable units of compute (like a single instance of a web application or microservice), you will have to design your own application level instrumentation to get the metrics you need. This quickly becomes challenging.

As instrumenting the application to fully understand resource consumption at the required granularity is typically challenging (and costly), it may be worth asking yourself a question - do I need to calculate the exact costs incurred, or perhaps approximate costs are good enough? The answer will depend on your pricing model.

Pricing Models

There are many pricing models for solutions delivered using a SaaS business model. All of them are an attempt to ensure that the solution is profitable while providing an attractive return on value to the customer. This makes their relationship to COGS more or less direct.

A very common pricing model that is strictly related to the COGS is the consumption-based pricing model. In this model, you charge your customers the exact costs they incur plus your margin. Obviously, you can’t charge the customer for “X GB of storage, Y hours of CPU, and Z hours of John”. The customer needs to be charged for the value they receive. You can charge directly for things like storage or the time it takes to run certain processes (like data ingestion or analysis). For other things that don’t represent the direct value to the customer, you have to figure out a framing that does. This framing often leads to the second pricing model - per-unit.

In the per-unit pricing model, you charge your customers for a logical unit of a value. This could be an API call, a user, an active user, or perhaps a connected device. It all depends on the business context. This model isn’t so strictly tied to COGS. You don’t have to measure the exact cost incurred by the unit, but you do have to calculate the approximate cost that the unit might incur. This is technically easier (because it doesn’t require such precise instrumentation), but more risky from a business perspective. The reality is that units are not exactly the same. You need to calculate this approximate cost at a level that an average unit will not exceed too often. If you try to be too far on the safe side, the price will be too high and customers will not consider your solution to have good return on value. If you try to be too aggressive, the actual cost of a unit will exceed the price too often and the solution will end up being unprofitable. This is a typical risk that SaaS solutions must balance, and it grows with the last common pricing model.

The most risky pricing model from a COGS perspective is flat-rate pricing. You charge customers a flat fee to use your solution. This model is often requested by enterprise customers because it is simple and predictable from their perspective. To protect the profitability in this model, you need to think about COGS a little differently. In addition to calculating costs (at least approximately), you need to set usage limits. There should be two parts to these usage limits: a fair-use policy that explains them to customers, and safeguards (such as rate limits and throttling) built into the solution that enforce them. You can also add some differentiation to the flat-rate pricing model by introducing feature- or service-level-based tiers that increase the correlation between what your customers pay for and the COGS.

Of course, ensuring that the price covers the cost of the solution is only one side of ensuring profitability. The other is ensuring that the cost is as low as possible.

FinOps in the SaaS World

The classic approach to FinOps includes two activities: cost reduction and cost avoidance. Both of them exist and are extremely important in the SaaS world.

Cost avoidance takes exactly the same form as everywhere else. You have to constantly analyze how the architecture of the solution is impacting costs and look for ways to optimize it.

Cost reduction requires a slightly different approach. You still want to use things like reservations and savings plans to minimize your costs, but you need to plan their use in the context of your sales process and pricing model. For example, it is quite common for customers to find ways to minimize their usage in consumption or per-unit pricing models in order to minimize their costs. So basing your reservations on current usage can backfire. With flat-rate pricing, you need to know the cancellation risk and notice period for each customer so you can reserve only what you need.

Costs and Pricing Over Time

When it comes to the cost of your solution, you should be constantly on the lookout. One thing is estimating and measuring how architectural changes will impact COGS. The other is trying to anticipate how new features will drive adoption or usage and impact COGS.

Therefore, your pricing model lifecycle should also be a constant consideration. You should be actively thinking about whether you need to add new or retire existing tiers, change the price, or perhaps migrate to an entirely different pricing model.

As a technical leader, you are responsible for the profitability of your solution - your job literally depends on it.