How To Start A Dev Tools Company with Nicolas Dessaigne | Startup School

**Nicolas Dessaigne** (0:09)
Hello, my name is Nicolas Dessaigne, and I'm a group partner here at YC. Before that, I was the co-founder and CEO of Algolia. Algolia is a search API used by millions of developers to build a great search experience in their apps and websites. And it's relevant today, because today we are going to speak about DevTools and how to start a DevTools company. So here's what we're going to cover. First, we'll discuss about the founding team and how to find your idea. Then, how to start the company, from the prototype to the MVP. And finally, we'll dive into the go-to-market, including sales and marketing for DevTools. But first, what is a DevTool? So a DevTool is software that is used by developers to help them build products. And that includes a lot of aspects, from coding, testing, debugging, documenting, deploying, running. It's all of the gamut of aspects of their job. And it's a broad category then. You can think about IDEs, like VS Code, API, like Stripe, Twilio, or Algolia, my company. Library and frameworks, like React, Node.js, or Longchain. Or even infrastructure or cloud services, like AWS, or Verso. And many other tools, Docker, Terraform, Datadog, GitHub. You get it, it's very diverse. And at YC, we've supported many of these DevTools, hundreds of them. And we already have two public companies, GitLab, the open source GitHub, and PagerDuty that started as a simple alerting system and now is used by half the Fortune 500 companies. And many others, you probably know about Stripe, Docker, Heroku, SuperBase, Segment, Post Hoc, Apollo, AirBite, and also Algolia, of course. And we've learned a lot from them. So let's dive in and start at the founding stage. Well, first you need a founding team. And the key aspect of DevTools is that you are going to build a technical product for developers. Obviously, you need to be a developer yourself. Most of our co-founding team for DevTools are all developer teams. And the great thing about DevTools is that developers are actually using DevTools every day. So when you are building a DevTools, you're basically helping yourself in your action of building a product. So let's take a step back and chat quickly about what are good and bad DevTools ideas. And as a professor, let me start by telling you that with the advent of LLMs and AI in general, it's actually very difficult to know for sure today what's a good or bad idea. The bad ideas, the tarp ideas of yesterday, could actually be possible to make successful now thanks to LLMs. Some ideas are actually more difficult than others. Developers every day are going to work on things they are actually not going to like, like documentation, QA, testing. And these become obvious ideas for them to fix for others. The problem here is that they are not the only one to think about it, and that creates a lot of noise, and that's why there are so many of these on the market. Do you really want to build the next, yet the next QA tool for other developers? Hmm, I don't know. Another way to look at it is the difference between build time and runtime ideas. So the QA testing, all of these ideas are build time ideas, things, tools you are going to use when you are building the software. It happens that these ideas are mostly nice to have. Well, you could build your product without them. What's more interesting are runtime ideas. Why? Because at runtime, it becomes really critical. It must have products. If you bet on an API, for example, you cannot run your own product if it's down. That's why it's more critical and it's way better idea for DevTools. The other advantage of these runtime ideas is usage.
Because the more your customers are going to grow, usually, the more they are going to use your product. So your incentives are aligned. Think about Stripe, for example. If their customers sell more product, they make more money, everyone is happy. Much better idea. Another quick category that I can touch upon is libraries and frameworks. These can be great ideas, usually open source, but they can also be very challenging to monetize. Think about Pandas, for example. Very difficult to make money out of that. The one way you can monetize these ideas is by offering a hosting service. Think about Next.js and Verso, for example. Okay, last point I wanted to touch on this idea, which is the LLM and AI trend. Actually, with this change in the world, there are many new DevTools being created. And it's awesome. It's so exciting to work on a DevTool that's going to help these companies building LLMs. But it's also a time where the market is very nascent. So an obvious great idea is LLM observability. Well, it's obvious, right? Anyone building with LLMs, they want to know how they are doing. They want to be able to evaluate them. Guess what? Many other companies think the same thing. And that's why we have dozens, if not hundreds, of such companies out there. It doesn't mean that it's a bad idea, but I think that if you are starting in that space, you need to have a clear idea of how you are going to differentiate yourself. Or are you going to win against all of these competitors? Okay, which leads me to a few mistakes people often do. The first one is waiting for the perfect idea. You are going to wait for a very long time. Let me go back to these LLM observability ideas. I would actually encourage you, if that's the idea you have, just start. That's okay. Even if you don't differentiate yourself right away, that's okay. You learn as you go. And eventually, you'll be able to put it off or you'll change your idea. Which leads me to my second mistake, sticking with the wrong idea for too long. You may not realize, but 50% of the companies in YC eventually pivot from their first idea. It's huge. And it's also true for DevTools. Finally, last mistake, thinking you need a business founder in the team. I know that's what I start when I created Algolia. We need to create Algolia with two tech co-founders, but it crossed our mind. Hey, we don't know how to sell. We need to hire or to find some other co-founder who knows about sell. No, it's actually way easier than you think to learn how to sell your product. Actually, we check the numbers. 74% of YC DevTool companies had only tech co-founders, and that's compared to 45% for all of the other companies. Okay, so now that you have a team and an idea, where do you start? Well, there is only two things you have to do, build and talk with users. There is no specific order. You can actually start by talking with users because they are going to help you figure out if your initial idea is good, or you can start by building a prototype so you can get easier feedback from users. Let's speak about that prototype. The most important thing here is not to over-engineer it. You should do that quick and dirty, and I know that it can be very difficult for some developers out there, especially for experienced engineers who pride themselves on robustness and scalability of their code. But the truth is that the most important thing at that stage is to iterate as fast as you can. Rule of thumb, I would assume that you'll throw away 90% of all the code you write. So your goal at that stage is just to identify the 10% of what you're building that's actually valuable as fast as possible. And then later on, you can refactor this 10% only and avoid wasting a lot of time. As you iterate, of course, you'll want to speak with users and get feedback. It's completely okay to show them a prototype. Please don't wait to have a perfect product. Just show them a prototype and start gathering feedback as early as you can. And that will eventually lead you to an MVP, a minimal valuable product. And this word, the V, is important, valuable. You need to provide a value to your customers. It's much better to be 10x better on a very tiny thing for someone who cares about it. Working for a niche is completely okay. Once you have real customers who love your product, it will be very easy to expand from there. Let me give you the example of Algolia. Well, today, Algolia is a very broad, large, full-featured search engine, right? But when we started, to be honest, it was just a glorified autocomplete, very minimal. But that product was so much better than whatever else was available at that time that some people cared enough about it. When we started demonstrating it, we didn't have much to show. Actually, I still remember our first customer, that first meeting, when I did demo using a command line to index content. We didn't have any API client yet, we didn't have any admin UI yet, just a command line and then a very simple web page to show the search. That was enough to close a $2,000 a month contract. Okay, you have built something you can show users. So the next step is to talk with users. I know that many developers, many tech developers are actually introvert, and they don't like speaking with users or with customers, like they don't like sales. Well, you may not realize, but as you are building a DevTool, you have a huge advantage. You know your audience. You are your audience, you are a developer yourself, you speak the language of your customers, you are uniquely qualified to understand them. So you'll see, it actually will be way easier than you think. Please don't wait for the product to be ready. You want to learn ASAP right away if you are solving a real problem that people will be ready to pay for. But how do you find these users? Two things, outreach and launches. Let's speak about outreach quickly. DevTool co-founders often plan to have a bottom-up adoption model where individual developers are going to come inbound, try the product and convert, or maybe become their champions at bigger companies. Well, I have some bad news for you. Nobody knows you yet. So to get there, first you need to get people to know about you. And there is no other way to do that than outreaching and finding them yourself. But you need to be smart about it. Start with your network, your previous colleagues or classmates. And then you expand from there. Friends of friends, you can leverage LinkedIn, you can find like specific holes over there. But please, please personalize your messages. Like don't copy what you can see out there, sent by marketers. Actually, your developers, I'm sure you hate these messages. So don't do the same. Just ask yourself, would you be excited to open your message? Then ask your co-founder, ask other developer friends, would they be excited to open your message? And then read your email and then possibly act on it? Well, you simply iterate until they do. Now, let's speak about launching. You can launch many times, and that's what you should do here to get more attention. The best place to launch for DevTools, I would argue, is Hacker News. Hacker News is a community of intellectually curious people. Many of them are developers. And there is that section in Hacker News called Show HM. That's the perfect place to launch and gather feedback on what you are building. Again, like when you were writing kind of these outreach messages, please don't do marketing, don't try to sell your product. Just explain plainly and simply what's new and interesting in what you are building. That will be very engaging for the community, and they'll share comments to you. Engage with these comments. Don't let them unanswered. Try to engage with people asking questions. Some of them are going to be haters and be rude. Well, you should engage with them too, but your goal is not to convince them, it's just to convince any other readers who are going to read how you reply to these haters. Just be classy here. One of the great example here is Segment. They simply did an experiment by launching their next idea on Hacker News, and it blew up. They got hundreds of votes and so many comments that they knew they were on to something, and that became their idea. Another example is Olama. Olama helps companies run LLMs on their own machines. Well, it started on a comment on another post on Hacker News, and just from that, they got a few people interested.