Running a developer product or a developer relations team means making trade-offs about where to invest time, money, or focus. Being able to attach values to developers can make conversations easier across different business functions, and allow more direct apples to apples comparisons of things like the potential value of activities.
This kind of estimation is important for more than just deciding whether to do an event: with the growth of companies that attract huge audiences and then monetize, being able to reason about user or subscriber value is important when valuing a company. Valuation legend Aswath Damodaran at NYU Stern has an excellent paper where he breaks down his approach to valuing companies like Uber and Netflix, and we can use simplified versions of those same approaches in our domain.
What is a developer worth?
Imagine we run a software as a service targeting developers, as with a business like Twilio. Our revenue comes from metered usage of our service — when developers call our APIs, we bill them for each call.
For simplicity, let’s assume that is the only revenue source in the business, even though in the real world there are often licensing, support, consultancy and other ways of earning in the mix.
What is a developer?
The first question is: what is our unit of measurement. It’s easy enough to think “unique user IDs”, but it might well be a project or a billing account — a given user ID may be associated with multiple projects, and a project might have multiple users.
In general, its best to tie our unit to how the usage is paid for — if a service is per-seat (like say an IDE license), then per-individual is a good level. If the billing is per-project, then you will likely be best measured in terms of projects. Even, it’s probably worth going through and checking to see what the average number of users per project is, as that will help you evaluate opportunities by their audiences.
Secondly, developer products can often build up a lot of dead accounts, particularly if they are free to get started. This can add a lot of noise without being particularly helpful — many times a single human is behind both dead and alive accounts: for example, they may have tried the service on a personal account, but then signed up with their work email address for real usage.
Filtering out dead accounts is a good idea: common options include projects/users that have been active in the last 28, 7 or 1 days, and accounts with a minimum spend. As an example, to go back to our earlier reference Twilio count any account which spent $5 or more in the last month of the period as an “Active Customer Account”, which is the base unit they focus on.
The end result of this thought process should be a number: the number of “developers” under consideration.
Let’s assume our fictional company has 60,000 active developers, with active meaning they have associated a credit card with their account and used the service in the last month.
Current value
We can now start putting value against our developers. This feels like it might be easy — just divide revenues by the number of users. Let’s say our fictional developer product has revenues of $100m in the last year — not bad!
$100m/60k active developers= $1667/ active developer
OK, so a developer is worth $1667! Not quite. First, let’s look at the downside: things we need to account for.
That revenue isn’t free: it costs us some money to make our API do the things developers love. That’s the cost of serving requests, costs of networking, storage and perhaps fees paid to other providers that we use , ie. the variable costs. On top of that, we also want to attribute some of the costs of keeping the services running — the DevOps folks, the required maintenance and so on, ie. the fixed costs. Our accountants will keep these separate, which helps: segmenting the fixed costs that don’t change with amount of usage (roughly) like our DevOps team, from the variable costs, like our cloud IaaS bills.
Our company is pretty efficient, about 30% of every bill goes towards our variable costs, or $30M of our total revenue. Our fixed costs are about $10m. This leaves us with $60M, or $1000/active developer: still a very nice return!
That value, though, is far too low. While our users are metered, we expect them to stay with us over the long haul as we provide an important service to them. In fact, we’ve been pretty successful at getting them to use our service more over time. Those two things make each of our users a lot more valuable.
We want to consider the whole lifetime value of a developer, not just what they’re going to pay in year one. This is where we go from hard data to assumptions, and into the domain of modelling.
To know what a developer is worth, we have to help our financial folks answer three questions:
-
What is the lifetime? How long should we expect devs to stay using this type of service?
-
What is the retention rate? How many users drop out (say to competitors or home grown versions)?
-
How much will developers increase their usage of the service over time, if at all?
First off — what is the lifetime? Many developers that use our service do for apps and websites — how long do these things live? As a rule of thumb, I figure an app or site gets a pretty large change every three or so years. I also think that after three of those, the chances of it working the same way as when they first integrated are slim. Based on that my knowledge of our (fictional) customers, I’d say 10 years is a good lifetime — your product might be more, or less!
Within that lifetime, what % each year either stop needing the functionality the service offers or switch to a competitor. This data should be available historically, but it’s also worth looking around at the kind of rates more established competitors get, if you can find them. To use Twilio again, they mentioned in one presentation their annual retention rate is around 96% — we’ll use that same percentage for our fictitious service.
Finally, we need to know how usage is going to change over those years. This could be because our customers’ businesses are growing, and their usage grows with us, or because once they use some of our service it is easy to show them the value of using more. Let’s assume our average revenue growth (also called ARR expansion or negative revenue churn) is 10%.
With these, we can work out what the account is worth to us. To do that, we need to think about how much that money from year 10 is worth to us now. Intuitively, we can see that money in the future is less valuable than money now, but to quantify it we need one more number, how much to discount those future earnings by.
This is based on something called the weighted average cost of capital. In general, this will be a number finance folks will have a handle on, and for our fictitious company, we’ll say that’s 10%. We can then discount our future cash, and sum up to get our lifetime value of $8,371 / active developer.
Total is our per-user value from our existing users
Note that this is a pretty simplified treatment — we haven’t considered taxes for example, or more . It is also treating all developers as roughly equal, which they probably aren’t — but as a point estimate, it gives us something to work with.
What is a new developer worth?
Having a baseline number for our current developers is great, but we want to grow our business as well. In fact, we are spending on that right now — commissions for our sales team, costs of free trials, advertising and brand awareness, developer evangelism, conferences and so on
We need to take all those costs and estimate how many new accounts we have actually bought in. For example, let’s say that we spent $10m on sales and marketing over the last year and that we grew by 10,000 active developers. That gives us the first part of the cost of acquiring those developers: $1000 each.
To be fair though, we probably have to factor in a percentage of our product development costs. Let’s say that we build out a new API — some of that may be allocated to our existing customers, as part of that growth in usage we discussed, but there is a good chance that we are doing it to bring in new customers too. The same is true of other investments, such as making a client library for a new platform or language.
Breaking it down, we estimate we spent another $5m on our engineering which we allocate to new customers, to growth, rather than servicing existing ones. That brings our cost per new user to $1500.
A new user is inherently less of a sure thing than an existing one. On top of that, as we grow we go from the developers who are well aligned with our offering into communities that are a little further away — this means our cost to acquire is likely to grow over time, and our ability to sustain growth becomes more challenging. Still — it’s easy to get dragged into more detail than we need.
For our case, we’ll work out the present value of the new users, just as with the current, except we’ll increase our discount rate to reflect the higher uncertainty. We’ll set the cost of capital of 12% rather than 10%.
That gives us a lifetime value of $7,776.00, minus our acquisition cost of $1500, for a new user value of $6276.
Making choices guided by value
Looking at the value of the developers we’re engaging with to gives ourselves some tools to evaluate how we’re spending our time and money. Having a model means we can start varying the inputs of that model, which lets us experiment with different ideas, and see what has the biggest impact. For example, here are some takeaways:
-
Focus on intensity of usage of current customers
-
Fixed costs are cheap if they bring in new developers
-
Even if you can’t measure the activities, you can look at the aggregates
Focus on intensity of usage of current customers. Helping developers get more value from the service, and therefore increase their usage of it, pays off in multiple ways. If you can push up the usage it directly boosts revenues and boosts lifetime value, and also value of new developers. When looking at product improvements, developer materials or developer engagement targeted at existing users focus on how to help them get more from the product, and use it more.
Fixed costs are cheap if they bring in new developers. Other good investments are things that are going to cause the product to appeal to folks that hadn’t been interested before, because they get cheaper as more users take advantage of them.
For example, if we wanted to offer some free trial credits to every new developer, we could spend (up to) $6275 per new developer and still come out ahead, but would only be capturing $1 of net value. In contrast if if we spend $6,275,000 building out a new Android SDK for our previous iOS only service, we’ll make that back on the first 1000 Android users to come across to the service, but then also on every Android developer after that.
Even if you can’t measure the activities, you can look at the aggregates. It is really hard sometimes to work out what the value of an engagement activity is — how much did you get from sponsoring that event, or from building out that VSCode plugin? However, if you look at those activities across a year, you can see how they turned out in aggregate, and that gives you a broad sense of what is working. If you increase your customer acquisition spending, do you increase your rate of new customers enough to justify it? If you are spending to acquire new customers (for example through a channel partner), are the costs commensurate with your lifetime values?
With all of this together you can start seeing whether your predictions about your business are right. For example, do you believe you have a strong brand within a community? Segment your developers in that community and see whether you have greater spend or lower cost of acquisition.
Understanding how developers contribute to your bottom line gives you a richer toolkit to work with in creating great products and more tools with which to build a sustainable business around them.