How to start a dev tools company: team, product, and go-to-market

Executive overview

Most dev tools fail not from bad code but from skipping the fundamentals: validating the idea fast, talking to users, and selling before hiring anyone to do it for you. Runtime products are must-haves; build-time tools are usually nice-to-haves — that distinction shapes your chances of building a defensible business.

The talk covers three stages: founding and idea selection, building from prototype to MVP, and going to market without traditional sales or marketing teams.

Developers building for developers have a structural advantage: you are your own customer.

Idea selection: runtime vs build-time

• Build-time tools (QA, testing, docs) are nice-to-haves — the customer can ship without them
• Runtime tools (APIs, infrastructure) are must-haves — if they go down, the customer's product goes down
• Runtime tools also align incentives: as customers grow, usage and revenue grow together (e.g. Stripe)
• Libraries and frameworks are often great but hard to monetise — hosting is usually the only viable path (e.g. Next.js + Vercel)
• Crowded categories (LLM observability, QA tools) aren't automatic no-gos — you just need a clear differentiation angle
• 74% of YC dev tools companies had only technical co-founders; a business co-founder is not required

Common early mistakes

• Waiting for the perfect idea — start anyway; you learn as you build
• Sticking with the wrong idea too long — 50% of YC companies pivot from their first idea
• Assuming you need a business co-founder to sell

Building prototype to MVP

• Prototype fast and dirty; assume you'll throw away 90% of the code
• Goal: identify the 10% that's actually valuable as quickly as possible, then refactor only that
• Show users a prototype early — don't wait for a polished product
• MVP must provide real value, even if narrow: 10x better on one small thing beats mediocre on everything
• Algolia launched as a glorified autocomplete with a command-line demo — enough to close a $2k/month contract
• Choose your tech stack based on your expertise, not what's fashionable

Talking to users and early distribution

• Start outreach with your own network; expand to friends-of-friends and LinkedIn
• Personalise every message — developers hate generic sales emails; write something you'd want to open
• Hacker News Show HN is the best launch venue for dev tools: community is intellectually curious and full of developers
• Don't market — explain plainly what's new and interesting; engage every comment including hostile ones
• Segment discovered their actual idea by posting on Hacker News; Ollama grew from a comment thread
• Do things that don't scale early: Stripe engineers sat with customers and coded alongside them
• Don't hire until you're confident the product provides real value

Go-to-market: open source decision

• Open source is expected if you're building a library, framework, or anything handling sensitive data
• Benefits: developers prefer OSS tools, community awareness, trust with enterprises (can shorten sales cycles by a year or more)
• Community contributions are usually rare and lower quality than expected — don't count on them
• Monetisation paths for OSS: managed cloud hosting, open-core (enterprise features behind a paid tier), or support/services (discouraged — misaligns incentives)
• For closed dev tools: usage-based pricing (APIs) or tiered plans (self-serve → team → enterprise)

Sales: founder-led until $1M ARR

• No one knows you at first — outbound is unavoidable regardless of planned bottom-up model
• Founder sells first; only hire sales around $1M ARR
• Hire technical salespeople — Algolia's first sales team renamed themselves "product specialists" and had to own that identity
• Post Hog's CTO runs sales, treating it as an engineering problem
• Never use a sales deck — demo instead; Algolia had no deck until $10M ARR
• Lean into the technical buyer: when tech has influence in the decision, win rate is far higher
• Bottom-up motion means checking if enterprise employees are already using the product, then helping management understand the value

Developer marketing

• Find the community first (Hacker News, subreddits, Discords) — be helpful, not promotional
• Launch repeatedly whenever you have something new — SuperBase does a launch week every quarter
• Documentation is marketing: treat it as a first-class product feature, not an afterthought
  • Algolia: a feature wasn't done until the doc was done
  • Developers write the docs; a docs team helps developers write better docs, not replaces them
• Support is marketing: engineers should handle support — it delights technical customers and feeds product insight directly back to the team
  • Algolia waited until hundreds of employees before building a dedicated support team
• Ask every engineer to do one marketing activity per month (blog post, meetup talk, demo tool)
• Traditional marketers rarely understand developers — founder-led marketing often works better for longer than expected
• Dev advocates make sense at Series A or later; hire from your community or open source contributors