Measuring growth for your API using the SaaS analogy

Up until recently APIs have been part of the tech domain almost exclusively. As they go mainstream, it’s becoming more and more evident that creating, launching and supporting an API is a highly iterative process between technology and business.

The emphasis on technology has not only reflected in the way APIs are designed, the teams behind them, and the people consuming them. It has also affected the way that companies measure the growth of their APIs. Unlike SaaS models, right now there are not standards to do this, and each company understands the value of their API differently.

Mark Boyd wrote an excellent article outlining key metrics to measure the value of APIs that put an emphasis on business aspects as well as technical and customer related impacts. But we want to take a step forward in this exercise, and also think how to calculate the overall cost of an API, and its lifetime value.

Instead of using CaC (Customer Acquisition Cost) like SaaS does, meaning, all the activities you need to do to close one deal, we’ll be talking about CoI, that is, Cost of Integration. And instead of talking about customer lifetime value, we’ll measure lifetime value per integration.

Breaking down the overall cost of your API

Hitch founders Bruno Pedro and Luke Miller have been thinking about this for a long time and raised interesting ideas during one of our APIchats. They’ve identified that the overall cost of an API can be broken into three key areas: development, maintenance and support.

• Development costs

This is the sum of all upfront costs that happen when you design and implement an API. If you already have an API, it relates for example to the cost of developing a new feature. A big chunk of this investment is the actual engineers needed to create the API.

• Maintenance costs

This area includes everything that is needed to keep the API up and running overtime. API management services, servers, etc.

• Support costs

Once you launch your API, hopefully you’ll have a growing community of users who will become customers. You will need to engage and support and support them, so your support teams, as well as the tools you use to communicate with users are part of your API support cost.

In a recent talk at itnig, Bruno Pedro explained that these are not ongoing costs. If we look at the evolution of the API overtime, we’ll see that at the beginning development costs will sum up to 100% of the overall cost, but once the API is launched they will decrease considerably, to the point of being 0% of the total cost:

Maintenance costs, on the other hand, have a completely different pattern overtime. In the development phase they will have zero impact on the API, but as soon as the API is released they will start increasing. If you look at the diagram below, you’ll see spikes which are related to possible bugs that you’ll need to fix. The flat lines correspond to all activities and systems needed to keep the API alive. Basically, we’re talking about infrastructure and engineering costs.

Finally, there’s your API support costs. These include support engineers, systems used to provide support, etc. How these costs will evolve is pretty straight forward: they will grow as your user base grows. The more users you have, the greater effort you’ll need to make to support them.

It’s interesting to see that while your development costs will decrease dramatically once you launch the API, and maintenance costs will remain more or less low, the biggest challenge will be how to scale your support function as the community grows. Here’s the final graph showing this evolution:

Calculating CoI

It’s important to know that these are not metrics to be applied to your whole API. Breaking it down into each of your integrations will allow you to really understand how each component of your API is driving growth for your business. Therefore the first thing you need to do is identify the top integrations used by the community.

So, going back to our CaC analogy, this is what the Cost of Integration formula would look like:

API lifetime value and payback period

Once you’ve identified this for each of your integrations, you can move on to understanding the other factor needed to measure growth for your API: your integration lifetime value.

To do this, you’ll need to be able to measure where your customers come from, then identify the customers that are using one particular integration, and finally calculate the lifetime value for those customers. It looks like this:

Finally, you’ll need to calculate the payback period. This can be achieved by dividing the cost of integration by MRR (monthly recurring revenue) for each particular integration:

Measuring API growth

Growth is not just revenue and profits. We’re looking for certain elements that will have a multiplying effect overtime. To measure growth, we will follow the same SaaS thinking: your integration LTV needs to be at least three times bigger than your cost of integration. If this doesn’t happen, it means you’re losing money: you’re not generating enough revenue for the cost of maintaining and supporting your integration.

On the other hand, you will need a payback period lower than 12 months:

Conclusion

An approach like the one suggested in this article can help you bring more transparency to your API operations, and make sure you’re investing on the right integrations and features: those that drive revenue and growth for your API.

But it also points to an area that has been largely overlooked by API teams: support. As their community grows, at one point or another they will need to think about how to scale it in a cost-effective way.

Do you need help with supporting your API community? We can help! Sign up now.

If you like this article, please click on the ❤️ button below and follow this publication so you don’t miss out.