Building for 26.9Mn developers (Go-to-market for Devtools)

Published in

Together Fund

12 min readJan 20, 2022

In the previous editions, we got a sneak peak into how Founder Led sales and Product led growth models work. But there is this segment that is developing rapidly in the shadows — Devtools and Devops. I am not a technical writer neither do I have ever directly worked in the space. But with genuine curiosity to learn and understand the shift that is enabling and powering all the SaaS apps, I have tried to articulate what has been happening at a very macro level.

For highly technical reads and to satify the urge of understanding more, I have been lurking around the streets of The New Stack, R/Devops, Who is Nmadi and SaaStr (to name a few). To synthesize and understand the growth journeys that a devtools startup goes through — we spoke to John Kim (Founder and CEO, Sendbird) and Rajoshi Ghosh (Co Founder, Hasura) to understand the landscape and identify some tactics that early stage founders can use to grow.

Developers like to build things and this is probably because the creative aspect of building things attracted them in the first place. And it’s not just technology, but also engineers translating their software construction skills into business that has led to multi billion dollar developer led businesses outcomes across the globe.

As Tyler Jewell rightly says — Dev Tools, Dev Infrastructure, and API as a Product (arguably the categories and segments where developers create things for themselves rather than others) comprise nearly 70% of all developer-led companies while comprising roughly 40% of the revenues.

Along with this there are a few trends that are changing the dynamics for the developer led startups:

Increasing cloud adoption is making it easier than ever for companies to adopt and build devtools at scale.
Shift of the top-down buying motion to bottoms up. Developers now have the budgets and the buying power.
Tech is changing at a very fast pace and most developers like to try out tools which in turn allows multiple tools to get tested and the feedback loops make the tech even better.

What has been happening in the last 5 years? 🔎

There was a time when Devtools startups used to struggle with fundraising. It has been a steady journey from $646Mn of venture capital infused into Devtools startups (in 2014) to the recently gathered VC interest where private developer landscape companies raised a RIDICULOUS $16B in Venture Capital in 2021 🤯 almost doubling all previous private company raises!

And gradually, the narrative changed from Will Devtools startups ever find investors 📉to Devtools becoming a growth story 📈!

Let us look at some of the few successes that directly or indirectly were influencing this activity:

Atlassian (maker of confluence and Jira) went public in 2015 at $21 per share and is now trading at ~$300 (as of Jan 2022) at a ~$80Bn market cap
Twilio, the cloud platform that enables developers to build real-time communications within software applications began trading at $15 per share and is currently at ~$215 (as of Jan 2022)
Stripe, the internet payment service (still private but amongst most anticipated IPOs in 20222) is currently valued at $95Bn
The recent astronomical success of public companies like MongoDB ($30Bn Val) and Elastic has created an investor feeding frenzy for would-be startups with open-source origins.
Microsoft’s acquisition of GitHub for $7.5B, the launch of GitLab (valuation >$16B)
Developer-focused tools that have gone public in recent years all have greater than 100 percent net retention, sometimes much greater.

Infrastructure Software companies are indexing to cloud for growth

Below is the list of companies with Valuations $1Bn+ spread across geographies (not exhaustive):

The rise of developer tools 🔗

Building software at scale is hard, as those who have read The Mythical Man Month know. Creating better software doesn’t happen just by hiring more engineers; you need better tools. In a similar way to how new technology multiplies the productivity of end users, developer tools do the same for developers.

The world has grown at a tremendous pace in the past few years, there is not denying that. This has resulted into a shortage of Devops engineers. Even if a company has access to these engineers, it becomes necessary to optimize for their time (and in turn ship faster). This frees up the bandwidth and helps the engineers to focus on what really matters.

Also, building software does not easily scale or parallelize, which leads to gross underestimates of timeline and budget that lead to bad business outcomes. To overcome these challenges, many companies building internal tools, some of which have gone ahead and have become big businesses.

Many large companies that build software invest heavily in internal tools for developers. There have been many developments and innovations inside big tech companies, as well as outside them, which take inspiration from the development process happening within those larger organizations like Blaze (Google’s build system) and Facebook’s Buck (which was later open sourced).

How does the landscape look like?

One blog is not enough to cover everything in the DevOps/ DevTools space. The periodic table tries to cover it briefly. You can click here to understand more about what these categories mean.

Tyler Jewell has done an incredible job to compile the list of companies, mapped them to different categories in the landscape. (the values are collective ARR and growth rates of each category)

Some key take-aways from the landscape and Tyler’s blog ✍🏽:

The combined revenues of application servers, Platform as a Service (PaaS), Low Code, and API as a Product businesses are collectively 2.5x the revenues generated by tools and infrastructure developers purchase to create these software systems. There are two drivers to this — one is pricing whereby many pre-production technologies are charged using size of development team (seats) as a proxy while production platforms are charged by the size of the environment. The other tendency is for vendors selling platforms to provide pre-production tools for free.
At the time this blog was authored, the median SaaS / Cloud public markets EV / Next 12 Month Revenue ratio is a whopping 15x, and if developer-led businesses are treated similarly they would carry a $0.6 trillion EV.
In the 22 segments tracked, there is usually a single vendor that makes up 15–50% of the segment’s revenues, creating a tail of vendors sharing the remainder.
28% of all Dev Platform revenue is driven to an API specific product offering.

We did some digging into the list of companies across each segment. You can find the detailed excel file here. 📜

Publicly traded companies have 95% of Dev Platform revenues, even though they only represent 9% of the 348 companies that make up the category. This dynamic also plays out in the Software Delivery Lifecycle category where publicly traded companies command 88% of the revenues.
The Developer Tooling and Developer Infrastructure categories have their revenues equally split across publicly traded companies and those that are private. This reflects the higher distribution of revenues across a broader set of vendors, and the aforementioned challenges that many platform vendors face making the jump from production into pre-production.
Code + Application security, API as a product, PaaS, Low code, Project mgmt + Agile are the categories which have noticeable traction over the last set of 5 years and clearly reflect in the trends that we are observing.

Trends we are observing in the segment.. 💹

A. Low code/ API first approach is going to take space: 88% of global Web traffic was through an API at the end of 2019, and it should be approaching 95%+ by the end of 2022. Some startups operating in this segment — Stoplight, Readme, APIMatic, Postman, SmartBear SoapUI Pro, APIFortress, SmartBear ReadyAPI, CA Technologies Runscope, API Science, APImetrics, and Moesif.

Postman (India) growth story: Untill recently 99% of the APIs were internal APIs i.e built for internal tooling and not to be exposed (private APIs not shared with external consumer). Most of the API companies that came out (circa 2009 onwards) were to focus on the external APIs (end user goal of API performance). No body used to address the internal API until Postman started doing this. APIs would change and front end would break. The product was a simple form on top of a UNIX tool which allowed you to have a simple UI to make API calls and then published it/ open sourced it to the world. The traction came in primarily because of the fact that this was a product that was written for a need that the founders understood, wrote it for themselves and there were people who had similar problems that they were facing. They decided to make it a company and they had around 600k users (all over the world) by then.

B. Accessing developer productivty is picking up steam: With developers spread across the world and with up-coming remote teams, there is going to be a need to measure producitivity to help big developer teams to focus their time better. You can’t improve what you can measure. Some companies operating in the space — Code Climate, Pinpoint, Jellyfish, Pluralsight Flow, Waydev, Insightly (India).

C. ML in Devops: Due to the complexity of connected systems from micro modulation and the need to reduce time-to-feedback of change will drive the need for the codes to be more autonomous. In the history of computer program it has basically been increasing levels of abstraction and productivity on writing if-then-else rules — from Machine language to Python Django. Supervised This will disrupt the way we have seen the landscape functioning till date. Some companies in the segment — Kite, Codota, Applitools, Test.ai, Walrus.ai, Deepcode, Stackhawk, Functionize, Sofy.

D. Workflow automation: Huge scope of automating the Devops process by combining tooling across Provisioning & Configuration, CI/CD, APM to Security, and Incident Management. Some companies here operating in the space — Atomist, Axiom.ai, CTO.ai, Architect.io, Quali, and StackStorm.

But, how do you build a DevTools startup? What should you focus on?

A. Core pillars to focus on 🧱

→ Focus on the pain point

Jamie Zawinski once said, “The best motivator in the world is scratching your own itch.” Most of the devtools startups that we have seen coming are from the techie’s urge to solve for a problem that drove them crazy.

And when you have identified the macro problem statement, go micro — i.e when starting out, it is of utmost importance that your product is relevant to small companies, individual developers. It allows you to get feedback quickly and then iterate more easily on it. That’s why at the beginning, gathering feedback from lots of different types of businesses will help prevent getting stuck on overly complex features.

Gradually go to Enterprise after testing and refining the product and identify features that will not be a burden on your sales cycle.

→ Understand the end user

Focus on who will use it, who will pay for it, where will it be used and how will it be adopted.

Understand the volume of the problem statement. Are there atleast 100 developers that would care to use the solution. Understand how big of a problem is this for the backend/ frontend team to execute. Does your tool make them 10x productive in what they are doing?

Answers to these questions will sort of define your GTM once you decide your segment in step 1.

→ Idea validation and feedback loops

Here documentation plays a very important role. What usually happens when you are too engrossed in solving a problem is that you might sometimes lack in the articulation of the problem. Definition of the problem statement and lack of documentation is one of the most first things that one should solve for to gather interest in the solution, especially when you are going open source. Startups such as Aviyel are doing a phenomenal job in making this happen.

In 2013, developer news and open source projects traveled mostly through word of mouth or informal posts that redirected to a GitHub page or StackOverflow thread, there’s now a standard media tour: ProductHunt, HackerNews, Twitter, Reddit, Quora, etc. Developers also look at npm downloads or GitHub stars to measure project health. Also a great podcast on building a community by Meghan Gill at MongoDB.

B. Some Business tactics that you can follow 🪜

A. Deliver a service that can be measured (subscription business — SaaS)

For ex. Twilio chargers on a per call basis (per minute, per text — everything has a cost described to it). There might be some cases where this might be harder to define but try to peg it to an outcome so that you can charge incrementally as you go on. This will help you grow with the business — as the customer does well, you will do well. If the value you are providing is high, there is a revenue stream that will go on forever.

Case study: Economics of Dropbox on AWS

Dropbox started with the lower tier i.e 1000 GB charged at $0.14/gb/month resulting into a cost of $140 per month. Within a few years this dynamics changed to Dropbox using 40mn GB at $0.055/gb/monmth resulting into a cost of ~$1.9Mn per month!

AWS took all the friction away from the onboarding process and once the customers are locked in, that’s when they started making money.

B. Try to replace something that companies are already paying for

The other thing that makes a good business model is replacing something for which companies are already paying for

When you are building a product that is nice to have, incremental and helps in some way but does not directly replace a line item it becomes tough to replace them. It is easier to convince prospects when you are replacing something by mentioning how you are better than them. Ex. AWS replaced Heroku

C. Provide an amazing user experience

Think like a consumer focused company, focus on PLG. You would want to deliver the value at minimum friction. This will in turn result into a high NPS for you. Developers talk a lot and they appreciate when some tools is solving their pain point for real.

C. Technical MOAT?

There are so many technological advancements with an unclear picture of what the future holds. People often try to find a solution by looking for one specific technology, like a single algorithm or one particular piece of code no-one else can replicate. But more often than not, technical moats take shape in many incremental improvements towards an idea that will be hard to copy in the short and medium term.

In the long-term all technology becomes commoditized because new technologies always come with us on this journey. All tech moats are temporary because there is always something coming up which makes it difficult to keep up with them and stay ahead of other competitors longer than expected: The tide rises ever higher each day we advance into tomorrow’s world! This means that at some point you must decide what is worth investing time and money while nobody knows how far they’ll get at any given moment — but we’re forever moving forward together as well!

What does it take for a company to have a moat? It needs to be anchored on customer value. If something is hard to replicate, that’s not going to protect your company from competitors — only if the piece of technology you have offers what customers want and are willing pay extra for. Otherwise, it’s just like a pond near your castle: nice but doesn’t do anything as far as protection goes.

Closing thoughts

We at Together fund are bullish on the developer led startups and happy to lend out a helping hand even at a pre-product/ ideation stage to help you out in your journey by connecting you to our expert network. If you are building in the space and would like to have a chat irrespective of the fundraise, hit me up at dushyant@together.fund.

Resources

Bonus landscape

We spent some time studying the landscape and charted them out. We wanted to see how does ‘Build from India for Globe’ pan out in each of these categories. This list is not exhaustive and we would like to have your support in filling the blank spaces — do tag the one we have missed out in the comment section. Please DM if you are building in any of these segments.