Pod Insights Y Combinator Podcast How To Start A Dev Tools Company with Nicolas Dessaigne | Startup School About this episode YC's Nicolas Dessaigne was the co-founder and CEO of @algolia, a Search API used by millions of developers to build great search experiences into their apps and websites. Today it powers over 1.75 trillion searches annually for 17,000+ customers worldwide.
In this episode of Startup School, @dessaigne shares his advice for founders building a dev tools company from the ground up— covering everything from team and idea to GTM and sales.
Transcript 0:09 Speaker 00 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?
0:54 Speaker 00 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 Long Chain, 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.
1:37 Speaker 00 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 14, 500 companies. And many others, you probably know about Stripe, Docker, Heroku, Superbase, Segment, Postalk, Apollo, Airbyte, 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.
2:21 Speaker 00 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 Devtool, you are 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 Devtool 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 tar-pit ideas of yesterday could actually be possible to make successful now, thanks to LLMs.
3:06 Speaker 00 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 abuse 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 Doug, QA, testing, all of these ideas are build time ideas. Things, tools you are going to use when you are building the software.
3:49 Speaker 00 It happens that these ideas are mostly nice to have. You could build your product without them. What's more interesting are runtime ideas. Why? Because at runtime, it becomes really critical. It's 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 a 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.
4:31 Speaker 00 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 NextJS 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 Dev tools being created.
5:13 Speaker 00 And it's awesome, it's so exciting to work on a Dev tool 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 LLM, 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 you 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?
5:55 Speaker 00 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 are, 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 pull 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.
6:39 Speaker 00 Finally, last mistake, thinking you need a business founder in the team. I know that what I start when I created Agolia. We ended up creating Agolia 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 sale. No, it's actually easier than you think to learn how to sell your product. Actually, we checked the numbers. 74% of YC DevTools 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.
7:24 Speaker 00 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.
8:04 Speaker 00 Rule of thumb, I would assume that you 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 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 viable product. And this word, the V is important, viable.
8:48 Speaker 00 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 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, like 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. And when we started demonstrating it, we didn't have much to show.
9:33 Speaker 00 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 webpage 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 founders 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 DevTools, you have a huge advantage. You know your audience.
10:16 Speaker 00 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 easier than you think. Please don't wait for the product to be ready. You want to learn ACP right away. If you are solving a real problem, then 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. DevTools 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.
11:01 Speaker 00 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 outreach 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,
11:46 Speaker 00 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 etch-en. That's the perfect place to launch and gather feedback on what you are building. Again, like when you were writing like kind of these outreach messages,
12:29 Speaker 00 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 Zelsha 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 examples here is Segment. They simply did an experiment by launching their next idea on Hacker News. And it blew up.
13:12 Speaker 00 They got hundreds of votes and so many comments that they knew they were onto something. And that became their idea. Another example is Olama. Olama helps companies run L L Ms on their own machines. Well, it started as a comment on a comment on another post on Hacker News. And just from that, they got a few people interested. And then shortly after they launched their product, it completely took off on Hacker News. They got like again hundreds of votes and they knew they were onto something. And they didn't stop there. They launched again and again every few months. Each time they had like new things to share and that continued to fuel their growth,
13:56 Speaker 00 creating a lot of excitement in the community. Hacker News, best place to launch. The last thing I wanted to touch upon here in that section is you should do things that don't scale. So again, you're here to learn as fast as possible from your users, what they like or not about your product. A great example of a team that did things that don't scale is Stripe. Early on, the Stripe team were going to their customers, small startups, and they helped them implement their own product, sitting side by side in front of the computer coding with them. That was not only a great way to make sure their users were going to be satisfied, were going to be actually excited about what they were building,
14:40 Speaker 00 but it was also a great way to gather invaluable feedback very early from their users. So it's completely okay to do things that don't scale if they lead to faster learnings. Okay. And here are a few mistakes to avoid. So you remember, the goal is to go fast and iterate fast. So please don't choose a text tag because it's cool, because you want to learn it. No, you should took it because of your expertise with it so that you can iterate as fast as possible. Other mistakes we touched, not talking with users. Please get that feedback as fast as you can, which also means avoiding overbuilding before getting that feedback. Maybe a small thing here, be careful about that feedback.
15:26 Speaker 00 Be careful about not misunderstanding some of the developer feedback. For example, they may share, they may tell you, oh, you should build your product. You don't care, you just want to know if they would use your product or not and why. Or they could tell you, hey, you know what, I could build this in a week, I don't need it. Well, guess what, you just build it yourself in a week. You should not mind about that, just move on and continue improving the product. Last mistake some teams do is hiring too early. Very early on, you don't even know if your product is providing value. Please don't hire anyone until you have convinced yourself you are working on the right idea. Let's now talk about go to market.
16:09 Speaker 00 And the first question you should ask yourself about go to market is your business model. More explicitly, should you be open source? Open source has become one of the main go to market for DevTools. And it definitely works as a business model, as many companies have proven, like Databricks, Elastic, Hashicorp, GitLab, all awesome, great companies. I would argue that you must be open source if you are working on things like a library of framework. That's what today expecting for the market developers wouldn't implement on top of a new framework that is not open source. You should also be open source if you are dealing with data, especially sensitive data. A new database would need to be open source.
16:51 Speaker 00 Or an API connecting with sensitive data in a CRM or maybe an HR needs to be open source. You could be open source, but probably don't have to be open source if you are working on other things like an API or maybe an application like a bugcracker. Maybe in that case, it's not as important, but still could be your differentiation. Open source has quite a lot of benefits. Your customers are developers, well. As you know already, developers prefer working with open source tools. It's also going to help you create more awareness through the community. It can be also your differentiation, like you could be the open source version of X.
17:30 Speaker 00 Think about Posto and Amplitude, or Superbase and Firebase, or Airbyte and Fivetrans. Great approach. Speaking of Airbyte, you could also receive contribution from the community. In the case of Airbyte, they got a lot of connectors contributed from the community. But I would be careful on that one. Most cases, you shouldn't count on them, because the quality of the contribution may not be up to your standard. And then you have to deal with the contributors. And that could be more, actually more difficult than you think. But in most cases, I would say that you should not count on them. Good contributions are actually pretty rare. And last benefit, but not the least, is the trust.
18:11 Speaker 00 And it's actually very important for large enterprises in the enterprise realm. Take the example of Medplum, for example, who is building a open source EHR. The fact that they are open source, I would argue, probably should help them shorten their sales cycle with enterprises by a year or more. There is one thing you need to think about, however, when you are creating an open source project. Maybe not at the start, but pretty soon, it's monetization. If you cannot monetize your product, you don't have a company. At some point, even if it's later in the life of the company, you'll need to earn money. There are many variants out there, but it's good to look at the common approaches.
18:55 Speaker 00 Some of the common ones are hosting, adding a cloud offer. So your customers may use your open source free self-hosted. But they could also pay for you to host it, so that they don't have to maintain it. Sometimes cloud version also have like some additional features like team management. Another one is being open core. In that case, usually have a special offer, typically an enterprise offer, that have advanced features that are not in the open source version. Or maybe they're on a different license. Common features are typically the ones that are going to be necessary for enterprises like SSO, audit logs, disaster recovery, SLAs, these kind of features.
19:36 Speaker 00 And finally, some open source companies charge for support and services. But I would actually discourage you to follow that monetization path. Because your incentive becomes to build the most complex product possible. So you can charge for support and services, which is a bad incentive. And if your product doesn't need too much support, then people are going to turn and not renew their support contract. And what if you are not open source? Well, for these dev tools, they are usually following one of two approaches. Either they are usage based, like APIs, Algolia, Twilio, Stripe. And so they charge based on the usage their customers do. Possibly they have a volume discount or enterprise specific options that are on the side.
20:21 Speaker 00 And the second approach is having some specific plans, typically like a good, better, best approach. Good is going to be the self-serve option. That's going to solve the problem of developers for a very low price. For the better options, usually are going to be interacting with engineering managers who are going to care about collaboration. That's going to enable teams, still can be self-serve. And the best option is higher up. You are talking to the CTO, it's all about security, audit logs, disaster recovery, SLA. And in that case, it's usually a sales-led approach. Let's speak about sales. So as a quick reminder, from what I was saying earlier, don't fear outreach.
21:04 Speaker 00 Even if most dev tools are going to end up being bottom-up and rely on inbound, only heavily, no one knows you at first. And so you need to start with outreach. That period of founder outreach is how you start. As you get more well-known. That's when you'll get inbound. Usually, you are going to have at that point more self-servive leads. And then eventually, you will end up hiring a sales team to sell to bigger icons, enterprise. So, should you hire a sales team? Well, I would argue that you should wait as long as you can. Start by selling yourself, don't delegate away. The truth is that you are the only person in the company today capable of selling your own product.
21:49 Speaker 00 If you, as the founder, cannot sell your product, nobody else can. As a rule of thumb, I would wait to get to about 1 million ARR before hiring your first salesperson. And even then, try to hire people who are technical, who at least understand developers. Because developers don't hate speaking with salespeople. I actually remember our first salespeople at Agolia. They decided to change their title on LinkedIn. And instead of like being sales or icon execs, they called themselves product specialists. And the nice thing here is that they actually had to own that status. They had to understand the product intimately.
22:31 Speaker 00 So it was kind of like a great incentive for them to be better at product. And a great way for them to open doors with developers who don't want to speak with sales. Another example, PostHug. Did you know that Tim the CTO is also their sales leader? Not a business leader, their sales leader is also the CTO. He sees sales as an engineering problem, which is a no-some approach for a dev tool. If you want to learn more about sales, you should also watch Pete's talk about enterprise sales, another startup school video. So, is it different to sell a dev tool from selling any other product? Yes, it is. You should have built a sales deck. Developers like, don't want to waste their time reading through a sales deck.
23:16 Speaker 00 You should show, not tell. Just do demonstrations. I think that's the best sales approach you can do for DevTool. At Algolia, we didn't have a sales deck before we got to 10 million ARR. So even our sales, like proper account execs, were just showing demonstrations when they were selling. And that was working so much better for everyone. You should lean completely in the tech aspect of your product. For example, at Algolia, we sell a lot to e-commerce players. And what we realized is that when the buyer is not technical and wants a turnkey solution, we always, not always, but most of the time, we actually lose the deal.
24:00 Speaker 00 But when the buyer is technical or if tech has a lot of influence in the decision, we win way more often. So we realized by leaning into that aspect of our product. We are an API. We are not like a turnkey solution. Well, we ended up like finding our ICP and having better success selling. Okay, and the last thing that is also true within DevTool is that most of them are bottom up. What that means is that a lot of people are going to self-serve even within enterprises. So instead of going top-down, just pitching your product directly, sales should also check if some of the enterprise employees are already using the product.
24:44 Speaker 00 And they should then focus on helping management understand what the product is already doing for them and how much more it could help them if they were to pay for more like new seats or features or additional usage. Okay, so the last topic I wanted to touch in this video is developer marketing. Your goal is to create a lot of awareness for your product because you want inbound. The first thing you should do is find your community. So it could be Hacker News or some subreddit or some Discord that are there that is related to what you're working on. But be careful. Your goal is not to sell your product just yet here. Just be helpful.
25:28 Speaker 00 Just establish yourself as the expert. And of course, people are going to start knowing you and trust your brand, your company. That will help you down the line. People will think about you when they have that problem. Launch often, that's very important. We discussed about the example of Olamah before. But that should also be done for the life of your company. Some companies even do launch weeks and have been very successful for that. It works great for open source, for example. Supabase is doing that once a quarter, burning all their news in one week a quarter to make as much noise as they can. Other things you can do. Make your documentation a first-class citizen.
26:12 Speaker 00 Documentation is often an afterthought for developers. They prefer coding than actually documenting their code. I would argue that documentation should never be an afterthought. It should be part of the product. Documentation is marketing. That's how people are going to interact with your product. That's actually the first place. People are going after your homepage and maybe your pricing page. Stripe and other DevTools have really raised expectations there. Developers have become very demanding. That's something you should invest in. At Algolia, we decided that the feature was not ever done until the doc was done. And documentation should be written by developers.
26:55 Speaker 00 You know, Algolia, even when we grew the team and at some point we created that documentation team, their goal was not to write the documentation for the developers. They were here to help developers write better documentations. For example, they built a tool where it would automatically insert API keys for people who would be logged in so that when they copy past the code, it would work right away out of the box, which made the documentation ever more useful for our customers. Speaking of things that developers should do, I would include support there. You should make support a huge part of your marketing. Your users are developers, right? Developers hate speaking to these level one support people
27:39 Speaker 00 who don't know anything about the product they are supporting. Engineers should do support. And that's going to lead to two great things. One, your users are developers. And when they interact with developers who speak their language, they are going to be way more satisfied. Actually, I have examples where someone would have shot to support. And then the developers, like the person doing the support, was able to actually fix the bug and deploy in production in like 20 minutes. And so that kind of like blew the customer away. Like they were so impressed, so excited about the product. And two, it's going to help your own developers much better understand your customers' needs. Because they are going to face the pain as they are supporting them.
28:23 Speaker 00 And that's a great way for them to be the better product. Taking the example of Argoia again, we actually waited until hundreds of employees before we built a dedicated support team. And then we actually asked our best engineering manager to build that team. Support was never a second-class citizen for us. So developers are doing documentation, developers are doing support. All of that is your marketing. Should you even hire a marketing team? Or when should you do that? Well, similarly to sales, I think founders should lead marketing for a long time, maybe forever, actually. To be honest, even at later stage, I don't know a single DevTools company that is happy with their CMO
29:08 Speaker 00 when they have a traditional marketing background. Why? Because traditional marketers, they don't really understand the persona. They don't really understand developers. Only other developers do. And developers really hate being marketed at.
29:23 Speaker 00 Please don't insult their intelligence. You know that because you are developers, right? Well, early on at Algolia, we were actually asking every single engineer in the team to do what we called a marketing hack every single month. A hack could be writing a simple blog post, or could be speaking at a meetup, or could be building a new search. All our best marketing at Algolia was done by developers. I would encourage you, as you build your marketing team, to make sure that you have a lot of developers in your marketing team, because they are the ones who know how to speak to your customers. You may ask, what about dev advocates? Well, I love the idea, because that means having developers in your marketing team.
30:07 Speaker 00 But it's also a very undefined role with often a lot of very fuzzy expectations. So it's difficult to measure, difficult to build accountability for. So my recommendation here would be to wait and first leverage your existing engineering team and ask them to do some form of marketing or dev advocacy. And probably at Series A or later, it starts to make sense to hire dedicated dev advocates. Even then, think about hiring from within or from your committee. For example, if your open source could be contributors or active or helpful Discord members, these are the best dev advocates candidates to join you.
30:51 Speaker 00 So let's wrap up and recap what we said here. Start now. Please don't wait for the perfect idea, because as you are going to build your product, even if it's not a perfect idea, you'll do the reps, you'll learn, and that will lead you to the best idea. If you don't start, you'll never get anywhere. Build quickly. Please, please don't over-engineer. You need to have that very fast iteration pace where you can learn from your users as you are building. Quick and dirty is completely okay early stage, and then you refactor what actually matters. Spend time with your users. Like, there is no way you're going to learn if you don't speak with your users. Learn from them. Do things that don't scale.
31:35 Speaker 00 Go to their office, spend time with them. Launch early. We have seen many of our videos where we say, there is no shame in launching early. People won't remember you if it doesn't work out. But you could get invaluable feedback that will lead you to work on the right product or build the right thing that people need. As you are building a dev tool, you should consider open source as your go-to-market. Observe the market, observe other players, how they have built their product, and figure out if open source is the right thing for you. But don't dismiss it. Think about it hard before making a choice. Don't forget, you are the best salesperson for your product. No one else is going to know your product or your audience as well as you do.
32:19 Speaker 00 Learning to sell is way easier than learning how to speak with a developer. And finally, you are also the best marketing person for your product. You know the language of developers. You know how to speak with them. You know where they are spending their time, the community. You know how to access this audience. Okay, that wraps it up for me today. Thanks for watching the video. And if you are building a dev tool, don't forget you can apply to YC anytime.
Previous Twitter vs. X: Product Lessons For Startup Founders | The Breakdown Next How David Lieb Turned A Failed Startup Into Google Photos | Backstory Page updated October 26, 2026 · transcript and summary are machine-generated
