What comes next for developer platforms?
How Ethan Kurzweil invests in developer platforms, what he avoids, and what he’s looking for next.
I feel very lucky to be able to publish this newsletter. The individuals we’re speaking with are operating at the top of their fields, and (as a result) I’ve learned something new with each interview I’ve conducted. This was especially true when I was joined by Ethan Kurzweil, a longtime partner at Bessemer Venture Partners who *very recently* announced he’s leaving Bessemer Venture Partners to do something new (stay tuned!).
Ethan is whip smart and has a long and successful track record of investing in great developer platforms including Launchdarkly, Twilio, PagerDuty, Intercom, Twitch, Sendgrid, HashiCorp and npm. I got to apprentice under him when I worked at Bessemer and it was very fun to revisit some of the investments we did together in this piece. Something that I love about Bessemer is that it’s a deeply intellectual firm. We hit on a couple of their investment theses in this interview – but I also think you’ll see the depth of thinking here come out across all of Ethan’s answers.
What’s in this installment?
The nuanced ways that B2D companies are evaluated by investors differently from standard B2B companies.
How investors look at OSS + Monetization. If the founding team is allergic to commercialization, then venture capital doesn’t make sense.
Traits Ethan looks for in founders + GTM teams of developer platforms.
What comes next in the world of devtools?! Have all of the “API Companies” been built?
A brief exploration into how AI might change the game for dev tools altogether…
When you evaluate investments in developer products, as opposed to a non-developer SaaS tool, are there any differences in what you're looking at from a metrics or business health perspective?
Obviously the metrics for SaaS companies are well trodden at this point, and we consider developer platforms to be a subset of that category, but there are some metrics that we give increased importance to.
Specifically, the net retention for a developer business should be best in class relative to all cloud companies, because if you think about it, the motion for a lot of these developer companies is usually a “try before you buy,” or a spreading-within-teams, land and expand type of motion. We look at net retention as a leading indicator of whether that ethos is there or not. Is this a product that's delightful and therefore developers use more of it? That's a key design parameter as to how you architect your business and it should show up in the net retention rate.
And then the other one we look at extra-closely for developer platforms is engagement; how engaged are developers with the product? How we evaluate this metric depends on the product type – if it's a volume based product then we look for volume: are developers putting in more data sets? Are they connecting it to more systems? Are they sending more flows, etc. through it? Twilio is a good example of this type of product. Alternatively, it could be the type of product where standard engagement metrics are logins and time on site because users live in the product to do something – this would be like an Intercom.
Bessemer is a very thesis driven firm. You developed a thesis around developer platforms which you published as “the laws of developer platforms.” The second law says that developer platforms need to grow with the business. Can you explain what this means and expand on how you’ve seen companies succeed and fail due to their (lack of) understanding of this principle?
It is my favorite law! In some ways the high level concept is pretty simple, as a developer platform a lot of time you're selling to the smallest companies out of the gate. Eventually, some portion of those companies will grow and become the Ubers and Whatsapps of the future.
Those were early customers Twilio had that grew big, and Twilio stayed to serve them. Every developer business has some chance of riding along with the growth of their customers to great success. And it's actually very important that as a developer platform, you don't just serve these very tiny companies, because it's very hard to make a business work that way.
That’s been a failure mode for many of our companies; they’re really good at serving companies with small company needs, but they don't grow with them. They don't evolve with their business. It creates a better business model when you can land small companies and have a much cheaper CAC, customer acquisition cost in those days, but then stay with them such that you have a long lifetime value. You're not getting graduated off of, which is the key failure mode that I was talking about.
So some good examples: Twilio and Stripe and PagerDuty and Confluent and MongoDB - those are all companies that have evolved to serve small and large scale companies.
Customers grow into using more and more of the functionality, they don't necessarily look to graduate. There are counter examples - we’re going to talk later about open source companies- I’ve found a lot of those don't build the right enterprise offerings or administrative functionality, so eventually businesses graduate to some other product or they keep using the OSS but build their own governance on top.
Bessemer has an open source investment roadmap, as well. One of the key pillars in this roadmap is monetization. How do you determine whether an open source company has gotten monetization right? Let me add a wrinkle – successful open source companies still only monetize a tiny percentage of their users— 5% conversion marks success. When have you seen open source work, and why does it often fail?
First off, we get this wrong a lot. We've been wrong many times, and it's not easy to tell. Sometimes the ethos that makes open source projects really successful is counterproductive to monetization. This is actually fine. The challenge is when us dumb venture capitalists come in and think, “Oh, this will be easy to monetize,” and don't check that anti-commercialization ethos out. Then you get misalignments across the team and the investors.
We had a very prominent investment with npm, where the ubiquity and reach of the product is humongous. It touches almost all of the fortune 500 companies in some ways that use it as a package manager and actually use the registry to be able to pull down packets in real time. When we tried to sell something we just weren't able to sell the right product that those businesses cared about using. So, a lot of times we get it wrong based on ethos.
Hashicorp is an example of where we got it right. When you get it right there is a commercial lens to the founding team or to the project creators – and it’s almost closer to a freemium business model. They are thinking about how to provide a free product for developers who just aren't going to pay them that much, such as hobbyists, educational institutions and small companies - and they’re bringing them some value. But they figure out how that value will change as companies grow, and they figure out what they can charge for. Back to our second developer law! Grow with your customers.
I feel like the trick is maintaining that developer love and positive sentiment while still shifting into the enterprise and nailing pricing. Are there any “rules” to doing this right?
Yes - there's another developer commandment we have about replacing budget line items in the enterprise that people are already paying for. Often when open source projects get started they aren’t replacing anything, it’s just new functionality. That’s good, you want to be orthogonal, it’s the right hook, but from there a product needs to go on and replace something which creates willingness to pay. A danger is to enjoy developing cool and kitschy functionality - certain devs will love it, but the CFO won’t sign off on spending for that type of thing.
Developer productivity is the middle ground - sometimes you can get money for it, but not as much as you’d expect. A lot of investments have gone into IDEs, to help devs be a little faster, but there isn’t a lot of money available for them - not high value enough. Productivity gains have to be constant to command a good price.
Talk to me about founding teams of developer products - what are you looking for and what gives you pause?
A couple of key qualities standout:
Do they love the problem that they're working on? I like finding a team with a narrow focus that has broad application and they are obsessed with the specific problem area. Stripe’s a great example - the narrow focus is taking payments, but everyone has to do it. Osiris, in our portfolio, is another good example. They are a security company focused on authentication - a problem that developers don’t want to have to solve themselves. So, the Osiris team can be passionately focused on this problem, and solve a real need for any internet company.
The founding team has to be incredibly focused on developer experience. I want developers to think, “ah, this is so pleasant” every time they open the product. Those are the products that catch on very quickly. Take Copilot - it’s a magical developer experience and as a result they love it. A lot of the early successful developer platforms reinvented the paradigm between developers and software. Devs were used to clunky, middleware tools with poor user experience, heavily reliant on deep searching through docs to get anything done. Fantastic DX gives your product a huge leg up. I think DataDog and GitLab both did a great job on these two fronts.
You've participated in rounds at every stage - from pre-seed to growth. When you're considering a developer company at what point do you start weighing the strength of the go to market team? Do you think about this at the seed/pre-seed stage?
Essentially I want to know whether the founding team has “go to market compatibility.” And yes, I would evaluate that even from seed stage.
We just made a small investment in a seed stage developer company where the team comes from Okta’s sales org. They’re obviously very GTM oriented - it’s a RevOps product and one of the team members went from sales to being part of the data team in RevOps so they have a passion for that problem. I love that they are very commercial and GTM focused.
All of that said - the GTM team doesn’t have to be perfect out of the gates - everyone has false starts. But, we certainly weigh this from early on, and as you get to growth stage you absolutely have to have a strong team to be considered. We’d really evaluate based on the data - looking at the CAC:LTV ratio, the payback period.
It feels like the DevTools landscape has matured a lot in the last decade. Many of the core API companies…have been built! Stripe, Twilio, etc, they all exist at this point. Are there more rocks to be overturned for APIs? What are you interested in now when it comes to DevTools?
I think it's true that a lot of the obvious, kind of high level categories of development have been taken.
A lot of the failure modes that we see are trying to reinvent something that just got reinvented two or three years ago.
The better products of the future will capture more data and use it to make the experience of software more personalized, custom etc. So, it feels like a lot of products are going to rely more heavily on large data sets and to deliver more personalization via machine learning. So - I think there’s an opportunity up and down the stack from data capture and ingestion, to testing and deployment.
The two false signals I see right now are taking developer products that were built 5-10 years ago and trying to improve on them - that’s unlikely to win. The others are what I’d call “AI fake outs” - the sort of false harbingers of AI where there isn’t really any “AI” under the hood - they’re just using AI for investor marketing purposes.
I disagree with people who say that LLMs aren’t going to work - of course they're going to work. We just have to fix some of the edge cases that create problems and improve on the developer tooling that enables teams to solve those problems.
How do you think about dev tools and web3? Where do they intersect? Where are they different?
I absolutely believe in Web3. I think DevTools are the answer to making blockchain more useful, just like DevTools are the answer to making LLMs more useful, and if we have the right products for developers to secure the functionality of whatever they're building the blockchain for and I'm talking about all the things, security, testing, observability, monitoring, quality, payments, all of that, built for this particular way of building software using distributed consensus databases, we'll see a lot more applications of it!
There are a lot of startups that see this opportunity too, but we don't yet have the sophistication of products necessary to really do kind of mission critical things we’d like to see on the blockchain today. It’s all still relatively new technology - ethereum is about 10 years old - we have much further to go.
So, the 8th law for developer platforms is to “democratize development.” AI democratizes development in ways we have never seen before. How do you think about the future of developer platforms given how AI is changing the development process as a whole?
Ultimately I think that we’re going to unleash all of the knowledge workers to be developers. The eighth law speaks to the fact that everyone gets the full functionality they need to do their jobs effectively, without necessarily waiting on another gating item.
But, the old way we were thinking about democratizing development was to build a system that allows a lot of people to have access where they previously did not - essentially providing specialized tooling for each of them.
That's like the stone ages compared to what is now possible with AI - which should, eventually, allow anyone to write code directly. It’s so much cooler, so much more advanced!
The first landscape we’ll see unfold is the initial set of copilot-like products - it’s likely Microsoft and OpenAI will win in this category but maybe we’ll see another, specialized coding assistant emerge.
The really interesting question is - then what? You’d have to trust all of your people to have this powerful functionality of building at their fingertips. The next wave, I think, includes a critical layer of security and code scanning, to ensure you’re not introducing new vectors of vulnerability and things like that.
A new stack for development will also probably emerge, because you’re not necessarily going to have technical people contributing all the time. Project management will also fundamentally change in this paradigm, so you’d need a new kind of JIRA. Developer environments, sandboxing, it will all change.
Lightning round questions!
What's the developer platform that you respect most?
Zapier. It's the ultimate democratizer of development for 4,000 different esoteric use cases and some not so esoteric use cases. And they built it in a way to allow anyone to use it.
Who is a developer go to market leader that you respect?
Adam Fitzgerald at HashiCorp. Disclaimer - he’s a Bessemer operating advisor. He is the best thinker to help companies structure developer evangelism programs at scale.
Unpopular opinion re dev tools?
That a lot of dev tools shouldn't be businesses. Many should be free or part of a larger developer platform offering. The difference between tool and platform can make a big difference as to whether you have a sustainable business.
How do you feel like you’re able to uniquely work with developer-first companies?
I’ll keep it to one for the lightning round: I’ve gotten lots of experience with false signals.
If you’re a founder working on a startup sometimes you’ll respond to a false signal and it’s hard to go back and unwind those choices—we have lots of experience with developer platforms and can help founders avoid those pitfalls.
Big thanks to Ethan for joining me for this edition! You can find Ethan on X/Twitter and LinkedIn.
Want more developer GTM expert content? We’ve got some amazing operators lined up in the coming weeks - subscribe, or share if you’ve found this helpful!
Super cool interview! Thanks so much. I was wondering if more could be said about this "I see right now are taking developer products that were built 5-10 years ago and trying to improve on them - that’s unlikely to win" any examples you could point to? I wonder 5-10 years seems like such a large timescale that I kinda find this false signal a bit ambiguous.