4.2.17

Eight laws for developer platforms

Programming the next startups to the language of developers

Not long ago developers were uninvolved in tackling the challenges and problems of the enterprise. That has drastically changed and most companies — not just in Silicon Valley but beyond — now view developers as the lifeblood of the organization. Bill Gates has gone so far as to say that “a great writer of software code is worth 10,000 times the price of an average software writer.

Today developers may be the most important decision maker in the technology space with more control over spending than ever before. This is a sea-change from ten years ago when technology decisions were made by higher-ups; now developers control the purse strings.

Developer platforms are empowering these decision makers in entirely new ways, allowing them to bring products to market much faster. Our team at Bessemer strongly believes in the power of developer-centric platforms to drive innovation.

In the spirit of this belief, we developed eight laws for investing in developer platforms. While not every company can address each law, they guide our investment decisions as the ingredients that make for the strongest possible developer platforms:

After reading through the laws below, check out how Twilio lived each of the eight laws.

Law #1: Delivers a service that can be metered.

Similar to SaaS companies, successful developer platforms need to deliver predictable, recurring revenue with opportunities for expansion. Because of the cloud, it is now easy for a platform provider to measure underlying usage. The best business models in this space take advantage of this by selling a service that scales up or down — and has hooks into the product to measure volume as it increases (or decreases).

Law #2: Grows with the business.

This rule runs in parallel with the first; as a customer’s business grows, so does the platform business’ revenue.

Developers often follow consumer models, where they expect something for free or cheap initially, so allowing developers to affordably use a product or service until it becomes mission critical enables developer technologies to get in easily (read: low customer acquisition costs) and expand (read: growing lifetime value).

AWS is a great example of this rule in action. Companies often choose AWS instead of running their own datacenter infrastructure because it’s cheap and easy to get started. But once a company scales up, there’s nothing cheap about it as AWS effectively prices its service to cost a significant amount right as their customer’s underlying businesses take off. By the time their customers have a successful business, the AWS bill for compute, bandwidth and storage is meaningful. As of 2017, AWS has an $11.5 billion revenue run-rate with 25 percent profit margins.

Law #3: Replaces something that companies already pay for.

Without replacing existing cost items in the enterprise, it is difficult to garner huge budgets from each customer, which in turn limits the expansion potential of each account. By replacing other products and established budget lines, developers can justify the cost more easily as it grows. If the end-user can save money using such a platform, even better.

Note that Atlassian has flourished in spite of being additive to a business in some cases as they are able to justify the cost through the productivity gains of collaboration. But the vast majority of successful developer platforms replace spend items — from Twilio (communications) to Stripe (payment processing) to New Relic (infrastructure monitoring) and beyond.

Law #4: Offers an amazing developer experience.

Enterprise products are notorious for their lack of attention to the experience of the user. Developer businesses have traditionally had this problem in spades. However, the modern crop of successful startups are heavily focused on consumer-grade design; this is a differentiator. It is very important to not overlook the high expectations of developers as the consumers of the tech.

By offering a seamless customer experience with as little friction as possible, or as we like to call developer experience (DX), developers can more quickly test a solution, appreciate the value proposition (or not!) and predict what sort of impact it will have on their technology stack.

Law #5: Receives tons of explicit developer love.

This may go without saying, but we’d be remiss to leave it out. When analyzing companies in the developer space, we look at what users are saying, regularly checking feedback on blogs, Twitter, ProductHunt, StackOverflow and other social sources to get a sense for how users feel about the product. NPS is just the tip of the iceberg as the best products receive accolades before you even ask users what they think!

Developers are very vocal and are happy to freely share what they like, and don't like, about a product.

It seems obvious to say that one should listen to their users but it’s so critical that we won’t invest in a platform (post-launch) until the user delight is evident. This applies equally to products geared towards developers and operations (e.g., dev ops) alike.

Law #6: Exhibits strong network effects.

Is the tool or platform more useful as more developers use it — similar to a social network like Facebook? Cloud delivery provides a mechanism to enable strong network effects for software companies — not typically a type of technology company one associates with network effects. Developer businesses can benefit from the collective action of the crowd in a great many ways beyond typical economies of scale given the buying power that comes with high volume.

Github, npm and Stack Overflow exhibit this rule in spades — as the utility of these services is directionally proportional to the number of contributions from the crowd.

Law #7: Eliminates the need for non-core skill sets that no one enjoys.

The best opportunities for successful, sustaining developer platforms target specific skill sets that developers see as ancillary and not core to their main product or service. For example, very few developers enjoy building payment processing technology. It’s a challenging, technical area that generally isn’t core to the organization. This created a huge opportunity for Stripe and other developer-focused payments companies to obviate the need to internally develop these competencies.

The best strategy is to identify areas of development that can consume large amounts of time but where building better technology doesn’t deliver a core benefit to the organization. For example, building incident resolution software and connections to the hundreds of different core systems in the enterprise to help the operations team better address problems generally is not a core skill set of the operations team. Our portfolio company PagerDuty makes it so that it never needs to be.

Law #8: Democratizes development.

Another variant of developer platforms aren’t sold to the developer at all. Instead, these types of low code or no code platforms empower non-developers to accomplish tasks that previously required coding skill and were generally built bespoke. This speeds up the overall development cycles of the customer of the platform — as a business user without technology knowledge can iterate without waiting for developers to get involved.

For example, our portfolio company Intercom allows users to embed communication tools into their customers’ products without more than a few lines of javascript code. Wix empowers users to easily create rich websites with little or no technical skill using drag and drop tools. Shopify allows merchants to build a web presence and accept payments with absolutely no coding required at all.

The world is becoming more programmable, requiring much more rapid product velocity for the best companies to keep pace. Building everything in-house is no longer the right solution for most organizations — even the most sensitive ones like the federal government — creating a massive opportunity for developer platforms to monetize this need for functionality. The result for the rest of us will be faster and faster development cycles on all of our favorite products and services, and opportunities for other startups to build useful services quickly out of the gate.

When AWS launched, the service was heralded early on as enabling an entire new class of startups to get off the ground more quickly than the old days of racking and configuring servers. As a result of the modern developer platform outlined here, we will have an order of magnitude greater impact on the ecosystem in terms of the creativity and product velocity that is unleashed. Not all of these platforms will inherently be great businesses and we hope that by open-sourcing our thinking as to what separates the best companies from the pack, we will help future generation of platform builders architect their businesses to last from the very beginning. This space is still young and a lot of change is ahead.