Developer services are an umbrella term for any kind of pay-per-usage developer product, usually provided as a hosted service. The majority of AWS, Google Cloud and Azure services fall into this bucket, as do numerous others. It is a relatively simple model, pay for what you use, but it has a host of challenges to building a great, sustainable business.
Getting SaaSy
In general, this is a form of Software as a Service, so the core principles of SaaS businesses apply. Specifically, key measures include:
Lifetime Value (LTV). This is the value of the customers usage over the time they use the service.
Monthly Recurring Revenue (MRR) / Annual Contract Value (ACV). How much cash will be coming in the door each month, or each year.
Customer Acquisition Cost (CAC). The cost of bringing a new customer into the business, e.g. via a sales team (and paid commission), through advertising, marketing, promotions, a free tier, or some combination of them all.
Churn rate. This is a rate at which customers stop using your service. There are two kind of churn to care about: customer churn, and revenue churn.
Balancing these is at the heart of the SaaS business. If your CAC is less than LTV you make money over the long term. If it’s too much lower, you may be vulnerable to competitors.
If the customer churn rate is high you’re going to spend a lot of money acquiring new customers. Average LTV may also be distorted by a small number of large customers, which makes you vulnerable to shifts by them.
MRR and ACV tell you about cash in the door. Even a high LTV doesn’t matter if you run out of cash before the end of that lifetime! When the company is growing, the lag between the immediate costs of growth and the delayed revenues can tricky, and require outside funding or debt
Developer Service specifics
Integration costs. Every SaaS has some integration costs, but they can vary by a large amount in developer products. On the low end, a new analytics product may be as simple as dropping an SDK into an app or some JavaScript into a container, while on the high end a new database may require rewriting a significant chunk of application logic.
Network effects. There can be developer side network effects on successful developer products — if a developer becomes familiar with your service, they increase the pool of available talent, and may spread it to other projects they work on. This tends to increase the winner-takes-all effect in some spaces.
Complementary products make a service more valuable. These are either overlapping products from a single company or multiple integrations with a service. These increases the developer-side surplus (the amount of value in excess of the price paid the developer captures) and therefore pushes out the demand curve for the product.
At the extreme, the core technology itself may be complementary to the revenue generating parts. For example, push messaging service OneSignal is free, but makes money two ways. They sell marketers data on app and notification trends extracted from their integrations, and they offer premium support for a fee. This kind of add-on service is a common model for consultancy oriented firms, where the business is professional services on top of a free product.
Margins & Revenue Management
If you’re writing a SaaS word processor, the chances are that the costs cover the compute and storage requirements by a large margin, and each new user within a customer lower the overall usage rate. With developer services billing is often based on direct usage, which means marginal costs can be more significant.
As an example, a file storage service has real marginal costs for the bandwidth and the storage of files. For many developers, these underlying resources will be hosted on IaaS providers, so the marginal costs are direct cost-of-goods. If the services are self-hosted, the costs will be a mix of service costs to the data center and depreciation charges spreading the cost of the capital investments in hardware.
Holding the capacity for customers to use isn’t free. This leads to a situation where most companies hold more capacity for delivering service than actual service delivered.
This makes some proportion of the service is perishable. That is, that there is a cost incurred regardless of usage, and part of the economics of making dev services profitable is finding ways of having high utilization of the resources.
In the airline and hotel industry, this is known as revenue management. The key idea is segmenting customers to be able to sell to the right developers, at the right time, for the right price, and to allow effective forecasting. The goal is to boost the utilisation, through use of price, promotion and other options, while not compromising your ability to earn high margins when you’re delivering the most value. This generally happens across four dimensions of segmentation:
-
Channel — how is customer reaching your service? Developers who are signing up for a free trial and adding their credit card can have a different set of needs and expectations than a company looking to sign an offline agreement. Developers working in agencies typically have a different incentive structure and may pay more for a service that is easier to bill through to their customers.
-
Cost — different types of usage may have different underlying costs, and those should be reflected in the billing model for the service. Similarly, different companies may have different servicing costs: a large customer may use more support time or other non-service resources. Finally, think about acquisition cost: if you are driving increased usage but from your most expensive channel (perhaps through a partner), are you better allocating more resources to more profitable channels?
-
Usage — what are the key drivers that the customer is trying to pay for? A popular example is spot pricing on AWS where users self-segment by buying a fixed duration of service for a discounted price.
Pricing is the main tool you have to maximize revenue, but not the only one. Too many pricing options or too many pricing changes are harmful, but price can be a big lever if used in a targeted way. For example, perhaps you integrate your service with another provider in an emerging market and offer a lower, bundled price. That doesn’t take away your pricing power but allows you to profitably sell capacity you couldn’t sell to higher value markets.
An Example — MongoDB
As an example, let’s look at the 10K from MongoDB. MongoDB is a popular NoSQL database that was the winner out of a scramble of open-source based DB businesses a few years back and went public at the end of 2017. Their annual report both sets out why the area is a good business, and how they have succeeded in it, including their transition to a SaaS model from a more traditional licensing type model. The whole report is worth reading, but we can grab some highlights here.
The database market is one of the largest in the software industry. According to IDC, the worldwide database software market, which it refers to as structured data management software, was $44.9 billion in 2016 and is expected to grow to $63.3 billion in 2020, representing an 8.9% compound annual growth rate.
One thing we didn’t talk about before was Total Addressable Market (TAM). This is an important concept for projecting the future usage. It’s a key number for investors, and worth thinking about if you’re in the early days of building a developer product! As the report notes, there’s money in databases.
Our business model combines the developer mindshare and adoption benefits of open source with the economic benefits of a proprietary software subscription business model. To encourage developer usage, familiarity and adoption of our platform, we offer Community Server, a free-to-download version of our database, as an open source offering, analogous to a “freemium” offering. This allows developers to evaluate our platform in a frictionless manner, which we believe has contributed to our platform’s popularity among developers and driven enterprise adoption of our subscription offering. The economic attractiveness of our subscription-based model is driven by customer renewals and increasing existing customer subscriptions over time, referred to as land-and-expand.
This is the core of the business. They cover both customer acquisition through their free community edition and the benefits of a recurring revenue subscription business model.
In 2017, 7% of revenue came from their (new) hosted Atlas offering, 68% from licensing, and 8% from professional services. They have 5700 customers, 36% outside the US, and no single customer represents more than 10% of the business — this is an important note that they have the flexibility to operate without a hard dependency on one customer. They’ve seen revenue grow quickly: 50% a year since becoming a public company. In 2018, sales and marketing were equal to 71% of revenue, driving that ongoing growth, and reflecting the mismatch between the short-term costs, and the longer lifetime value of the customers they add.
As they note in the risks section: “The timing of our sales and related revenue recognition is difficult to predict because of the length and unpredictability of the sales cycle for our offerings”.
The average cycle quoted is three to nine months, which is a significant investment before any revenue is booked, and then the income will be spread across the life of the customer. Their contracts for the licensed product are around 1 year, so churn rates (or more positively, renewal rates) are key.
The subscription services have a pretty solid margin: 78%, though that is likely weighted by the licensing based options which may have lower marginal cost. On top of the sales and marketing costs of 71% of revenue, R&D is 40%. Here, R&D is effectively work on MongoDB itself — the development of the database and associated services.
The report also covers the metrics they are using to evaluate the business internally, specifically ARR (Annual Recurring Revenue) and MRR, and “ARR Expansion”. ARR expansion is a form of negative revenue churn — revenue increasing per customer over time. Through 2017, that was 120%, meaning that they expect their customers to be spending 20% more each time they renew. This is exactly where you want to be as a developer product company, and is how, over time, MongoDB can match their expansion to the revenues.
While they might be making a loss now, MongoDB has plenty of cash in the bank to fund ongoing growth as a result of their IPO. Indeed, in their just-released Q1 earnings they note both ongoing growth of Atlas, a drop in quarterly losses as compared to last year, and a partnership with IBM, adding a new channel for the sales efforts.
Summing Up
Building a great developer product is only half the battle. Ensuring that you can take it to market affordably and price it appropriately are the keys to building a business that will thrive.
Luckily, much of what makes a great business is the same what makes a great developer experience. Understanding your customers, how they use the product, and how they get value from it is at the heart of ensuring the product is good to use, and ensuring you have a healthy business.