How To Start A Dev Tools Company | Startup School

Intro (0s)

• The speaker's name is Nicola D, and he is a group partner at YC, previously the co-founder and CEO of Algolia, a search API used by millions of developers to build a great search experience in their apps and websites (9s).
• The topic of discussion is about dev tools and how to start a dev tools company, covering funding, team, finding an idea, starting the company from prototype to MVP, and going to market including sales and marketing (34s).
• A dev tool is software used by developers to help them build products, including aspects such as coding, testing, debugging, documenting, deploying, and running (51s).
• Dev tools is a broad category that includes IDEs like VSCode, APIs like Stripe or Algolia, libraries and frameworks like React, and infrastructure or cloud services like AWS (1m12s).
• YC has supported many dev tools companies, including public companies like GitLab, PagerDuty, and others like Stripe, Docker, Hoku, Segment, and Apollo (1m37s).
• The discussion will cover the founding stage of a dev tools company, starting with the importance of a founding team (2m7s).
• The key aspect of a founding team will be discussed, although the details of this aspect are not provided in the intro (2m13s).

Founding Stage (2m15s)

• Building a dev tool company requires creating a technical product for developers, and it's beneficial if the founding team consists of developers themselves, as they can relate to the needs of their target audience (2m18s).
• The founding team can identify good and bad dev tool ideas by considering the current market and the needs of developers, keeping in mind that the advent of LLMs and AI has changed the landscape of what can be successful (2m47s).
• Ideas that were previously considered bad can now be successful due to LLMs, but some ideas are more difficult than others, and developers often focus on solving problems they face daily, such as documentation, QA, and testing (3m3s).
• However, these ideas can be crowded, and it's essential to consider whether building another QA tool, for example, is a viable option (3m27s).
• A different approach is to focus on the difference between build-time and runtime ideas, with runtime ideas being more critical and must-have products, such as APIs, which can be more successful for dev tools (3m54s).
• Runtime ideas also offer better usage and alignment of incentives, as customers' growth leads to increased usage of the product, making it a more attractive option for dev tools (4m17s).
• Another category of dev tools is libraries and frameworks, which can be great but challenging to monetize, especially if they are open-source, and one possible way to monetize them is by offering a hosting service (4m37s).
• Lastly, the trend of LLMs and AI can be leveraged to create successful dev tools, but it's essential to consider the current market and the needs of developers when evaluating ideas (5m7s).

AI Trend (5m10s)

• The current time is exciting for creating new dev tools, especially those that help companies building NLMs, but the market is also very crowded, with many companies having similar ideas, such as LLM observability (5m10s).
• Having a clear idea of how to differentiate oneself is crucial when starting in a crowded space, as dozens or hundreds of companies may be working on similar ideas (5m41s).
• Waiting for the perfect idea can lead to a long wait, and it's better to start working on an idea, even if it's not fully differentiated, and learn as you go (5m58s).
• Sticking with the wrong idea for too long is a common mistake, and it's worth noting that 50% of YC companies eventually pivot from their first idea (6m21s).
• Having a business founder in the team is not necessary, as technical co-founders can learn to sell their product, and 74% of YC dev tool companies had only technical co-founders (6m39s).
• The founders of Algolia, a dev tool company, started with two technical co-founders and learned to sell their product without needing a business co-founder (6m42s).

Where to start? (7m20s)

• To start a dev tools company, two essential steps are building and talking with users, and there is no specific order for these steps, as talking to users can help determine if the initial idea is good, and building a prototype can facilitate easier feedback from users (7m20s).
• When building a prototype, it's crucial not to over-engineer it, and instead, focus on creating a quick and dirty version to iterate as fast as possible and gather feedback (7m37s).
• The primary goal at this stage is to identify the valuable 10% of the code being built and discard the rest, as most of the initial code will likely be thrown away (8m1s).
• It's essential to show users a prototype and gather feedback as early as possible, rather than waiting for a perfect product, as this will eventually lead to a minimal viable product (MVP) that provides value to customers (8m29s).
• A successful MVP should provide significant value to a specific niche or group of customers, and it's better to be 10x better at a tiny thing for someone who cares about it, rather than trying to cater to a broad audience (8m45s).
• Expanding from a niche is easier once real customers who love the product are acquired, as demonstrated by the example of Algolia, which started as a minimal autocomplete feature but eventually grew into a full-featured search engine (9m4s).
• Even a minimal product can be enough to attract customers, as seen in Algolia's early days, where a command-line demo and a simple web page were enough to close a $2,000 a month contract (9m34s).
• After building something to show users, the next step is to talk with users and gather feedback to further develop the product (9m55s).

Talking to users (10m0s)

• As a developer building a dev tool, you have a huge advantage in understanding your audience since you are a developer yourself and speak the language of your customers, making it easier to talk to users or customers, despite being an introvert (10m2s).
• It's essential to learn from users as soon as possible, rather than waiting for the product to be ready, as solving a real problem will make people willing to pay for it (10m27s).
• To find users, two strategies can be employed: outreach and launches, with outreach being crucial in the early stages since nobody knows the product yet (10m36s).
• A bottom-up adoption model, where individual developers come inbound and try the product, is often planned, but outreach is necessary to get people to know about the product first (10m42s).
• When outreaching, start with your network, including previous colleagues or classmates, and expand from there, leveraging LinkedIn to find specific people, but personalize messages to avoid being seen as a marketer (11m13s).
• Personalized messages should be crafted by asking yourself if you would be excited to open the message, and iterating until it's effective, with feedback from co-founders and developer friends (11m36s).
• Launching is another strategy, and it's possible to launch multiple times to get more feedback and users, which is a recommended approach (11m54s).

Launches (12m0s)

• The best place to launch dev tools is Hacker News, a community of intellectually curious people, many of whom are developers, where there is a section called "Show HN" that's perfect for launching and gathering feedback on what you're building (12m2s).
• When launching, don't do marketing or try to sell your product, just explain plainly and simply what's new and interesting in what you're building, which will be engaging for the community and encourage them to share comments (12m28s).
• Engage with comments, including those from haters, but don't try to convince them, and instead focus on convincing other readers who will read how you reply to these comments (12m52s).
• Examples of successful launches on Hacker News include Segment, which launched their next idea and got hundreds of votes and comments, and AMA Olama, which started as a comment on another post and then launched their product to great success (13m3s).
• Launching repeatedly, every few months, can continue to fuel growth and create excitement in the community, as long as you have new things to share (13m44s).
• Doing things that don't scale, such as Stripe's early team going to customers and helping them implement their product side by side, can be a great way to learn from users and gather feedback (14m3s).
• Mistakes to avoid include choosing a tech stack because it's cool, not talking with users, overbuilding before getting feedback, misunderstanding developer feedback, and hiring too early (14m53s).
• When getting feedback, be careful not to misunderstand it, and focus on whether users would use your product and why, rather than how they think you should build it (15m24s).
• Don't hire anyone until you have convinced yourself that you're working on the right idea and your product is providing value (15m58s).

GTM (16m15s)

• Being open source has become a primary go-to-market strategy for dev tools and can be a successful business model, as seen in companies like DataBricks, Elastic, HashiCorp, and GitLab (16m16s).
• It is essential to be open source when working on libraries, frameworks, or dealing with sensitive data, as developers expect this and are unlikely to implement new frameworks or databases that are not open source (16m30s).
• Being open source may not be as crucial when working on APIs or applications, but it can still be a differentiator (17m1s).
• Open source has several benefits, including being preferred by developers, creating awareness through the community, and serving as a differentiator (17m12s).
• Open source projects can receive contributions from the community, but it's essential to be cautious and not rely on these contributions due to potential quality issues (17m37s).
• Good contributions from the community are rare, and dealing with contributors can be challenging (18m3s).
• Being open source can establish trust, which is particularly important for large enterprises, and can potentially shorten sales cycles (18m10s).
• When creating an open source project, it's crucial to consider monetization strategies, as a company cannot sustain itself without a viable monetization plan (18m38s).

Monetization (18m45s)

• To monetize a dev tools company, it's essential to earn money, and there are various approaches to consider, including hosting, open core, and charging for support and services (18m46s).
• Hosting involves offering a cloud version of the product, which may include additional features like Team Management, and customers can pay for the convenience of not having to maintain it themselves (18m55s).
• The open core approach typically involves offering an Enterprise version with advanced features not available in the open source version, such as SSO, Disaster Recovery, and SLAs (19m12s).
• Charging for support and services is another approach, but it can create a bad incentive to build complex products, and customers may not renew their contracts if the product doesn't require much support (19m35s).
• For non-open source dev tools, common monetization approaches include usage-based pricing, like APIs, with possible volume discounts or Enterprise-specific options (20m2s).
• Another approach is offering specific plans, such as a good-better-best model, where the "good" plan is a self-serve option for Developers, the "better" plan is for engineering managers who care about collaboration, and the "best" plan is for CTOs who prioritize security, audit logs, and SLAs (20m21s).
• The "best" plan often requires a sales-led approach, and it's essential to not fear outreach, even if most dev tools rely heavily on inbound marketing (20m54s).

Selling (21m10s)

• To start selling a dev tool company, begin with founder outreach, as it is the most effective way to get the company's name out there, and eventually, inbound leads will increase, allowing for the hiring of a sales team to sell to bigger enterprises (21m11s).
• It is recommended to wait as long as possible before hiring a sales team, with a suggested revenue milestone of about $1 million ARR, and to hire people who are technical or understand developers (21m55s).
• Technical salespeople are more effective in selling dev tools, as they can understand the product and communicate effectively with developers, and having a title like "product specialist" can be beneficial (22m17s).
• PostHog's sales leader is also their CTO, and they view sales as a nurturing problem, which is an effective approach for a dev tool company (22m46s).
• Selling a dev tool is different from selling other products, and it is essential to have a sales deck that shows, rather than tells, and to focus on demonstrations (23m8s).
• Leaning into the tech aspect of the product is crucial, as technical buyers are more likely to make a purchase, and finding the ideal customer profile (ICP) is essential for success (23m43s).
• Most dev tools are bottom-up, meaning that many users are self-serve, even within enterprises, and sales should focus on helping management understand the product's value and potential (24m22s).
• Developer marketing aims to create awareness for the product, leading to inbound leads, and is an essential aspect of selling a dev tool company (24m59s).

Marketing (25m10s)

• To start marketing a dev tools company, find the community related to the product, such as Hacker News, subreddits, or Discord, and establish oneself as an expert by being helpful, without directly selling the product, to build trust and recognition for the brand and company (25m11s).
• Participating in AMAs (Ask Me Anything) sessions and launch weeks can be effective marketing strategies, as seen in the example of Super Bas, which has a quarterly launch week to make a significant impact (25m41s).
• Making documentation a first-class citizen is crucial, as it is often the first point of interaction with the product after the homepage and pricing page, and should be written by developers, with the goal of making it a valuable resource for customers (26m6s).
• At Algolia, the approach was to consider a feature complete only when the documentation was finished, and a documentation team was created to assist developers in writing better documentation, rather than writing it for them (26m44s).
• The documentation team at Algolia built tools to make the documentation more useful, such as automatically inserting API keys for logged-in users, to make the code work out of the box (27m5s).
• Providing high-quality support is essential, as developers hate speaking to non-technical support staff, and support should be a significant part of the marketing strategy, recognizing that users are developers (27m25s).

Support (27m35s)

• Engineers should do support, as it leads to two great things: users are more satisfied when interacting with developers who speak their language, and it helps developers better understand customers' needs (27m38s).
• This approach can result in impressive customer experiences, such as fixing bugs and deploying in production quickly (27m56s).
• Developers doing support can gain a deeper understanding of customers' pain points, enabling them to create better products (28m18s).
• Aloya waited until they had hundreds of employees before building a dedicated support team, and they asked their best engineering manager to lead it (28m26s).
• Support should not be a second-class citizen, and developers should be involved in documentation and support (28m41s).
• Founders should lead marketing for a long time, as traditional marketers may not understand the developer persona (28m52s).
• Traditional marketers may not be effective in marketing to developers, as developers hate being marketed to and prefer authenticity (29m11s).
• At Aloya, every engineer was asked to do a "marketing hack" every month, such as writing a blog post or speaking at a meetup (29m28s).
• Developers should be involved in marketing teams, as they know how to speak to customers and create effective marketing strategies (29m50s).
• Dev advocates can be effective, but the role can be ill-defined, making it difficult to measure and build accountability (30m0s).
• It's recommended to wait and leverage existing engineering teams for marketing and Dev advocacy before hiring dedicated Dev Advocates (30m18s).
• When hiring Dev Advocates, consider hiring from within or from the community, such as open-source contributors or active Discord members (30m35s).

Outro (31m0s)

• To start a successful dev tools company, it's essential to begin with an imperfect idea, learn from it, and iterate to reach the best idea, as not starting at all will lead to no progress (31m0s).
• Building quickly is crucial, and it's recommended not to over-engineer, instead focusing on a fast iteration pace to learn from users while building (31m8s).
• Having a "crappy, quick, and dirty" approach is acceptable in the early stages, and then refactoring what matters is key (31m19s).
• Spending time with users is vital to learn from them, and doing things that don't scale, such as visiting their offices, can be beneficial (31m27s).
• Launching early is recommended, as it allows for invaluable feedback, and people are unlikely to remember if it doesn't work out (31m37s).
• When building a dev tool, considering open source as a market is essential, and observing the market and other players can help determine if open source is the right approach (31m53s).
• As the founder of a dev tools company, you are the best salesperson for your product, and no one else knows your product or audience as well as you do (32m10s).
• Learning to sell is easier than learning to speak with a developer, and you are also the best marketing person for your product, knowing the language of developers and how to access your target audience (32m17s).
• If building a dev tool, it's possible to apply to YC (Y Combinator) anytime (32m42s).