Cold Emailing Founders to Find What to Build

2. 1. The Premise: What You're Actually Doing

There are two ways to find what to build. The first is to sit alone and brainstorm. The second is to talk to people who already know. Founders of successful products sit at an interesting intersection: they've solved one problem in a space well enough to build a company around it, and in doing so, they've inevitably bumped into five adjacent problems they never had time to address.

The open-question cold email -- "what would you build next?" or "what's the biggest gap in your space that you're not addressing?" -- is not a standard cold email. It's closer to hiring someone as an unpaid advisor for 15 minutes. You're not pitching. You're not asking for a job. You're asking for their mental model of a territory they've already explored.

Most wannabe founders skip this step because it feels uncomfortable. You don't have something to show. You're not a peer yet. But that discomfort is exactly why it works -- founders get pitched constantly, they almost never get asked a genuine question with no agenda attached.

The second two questions are the ones worth asking. They're specific enough to get a real answer, and they're structured so that answering costs the founder almost nothing -- they already know the answer, they just haven't written it down for anyone.

3. 2. Real Cases: When Cold Outreach Led to a Business

These are documented, publicly-discussed cases. None of them are urban legends.

Zapier: Wade Foster found Andrew Warner on a forum and emailed him

In 2011, Zapier co-founder Wade Foster was looking for early adopters. He didn't have a product yet. What he had was a simple question: "Can we connect App A to App B for you?" He and his co-founders went through forum threads on Basecamp, Evernote, and Salesforce where users were asking for integrations that didn't exist. They found Andrew Warner, the founder of Mixergy, who had posted on a forum asking if anyone had built a PayPal/Highrise integration.

Foster cold emailed him. Warner had no idea who he was. The product barely existed. But the email was direct: "I saw your question about PayPal and Highrise. I think I can build that. Can I try?" Warner agreed. Foster built the integration in a few days. When Warner saw his first test form successfully sync to AWeber, his response was: "Oh my God, this is so great. How much do I owe you?" Zapier's first revenue: $100 via PayPal, from the worst onboarding experience imaginable.

The lesson here is not that cold email is magic. It's that Foster found someone with a specific, documented, unmet need -- and he reached out about that exact need. The forum post was basically a pre-validated customer discovery result. The cold email was just the bridge.

PostHog: a YC dinner conversation changed the company

James Hawkins and Tim Glaser had already pivoted PostHog five times before landing on product analytics. In early 2020, they were at a YC dinner with their fourth idea (a technical debt monitoring tool) when they started talking to other founders about what they actually needed.

The pivot to PostHog didn't come from a spreadsheet. It came from a specific conversation with the founder of Sentry: "We would never send all our data to third parties." That one sentence crystallized the open source product analytics gap. Hawkins went home that night, rewrote the product as an open source self-hosted tool, rebranded to PostHog, and launched on Hacker News three weeks later.

The YC dinner wasn't a cold email, but it's the same mechanism: an open conversation with a founder who had already mapped the landscape, revealing an unmet need that they couldn't address themselves. Hawkins was smart enough to recognize it.

PostHog is now valued at over $1B. The entire company exists because someone at a dinner said one honest sentence.

Birchbox: Katia Beauchamp cold emailed beauty CEOs

Before Birchbox launched, Katia Beauchamp had an idea for a beauty sample subscription box. But she had no beauty industry relationships, no brand partnerships, no credibility. She did have email addresses for CEOs and brand managers at major beauty companies.

She cold emailed all of them. Not to pitch a partnership. To ask for five minutes of advice. She framed it as: "I'm trying to understand how the beauty industry works. I have an idea. Can you tell me what's missing from how brands currently reach customers?" The conversations that followed gave her two things: a map of the industry's actual pain (brands couldn't afford retail customer acquisition, samples went to waste), and warm relationships she later converted to real brand partnerships for launch.

Birchbox launched in 2010, grew to $200M in revenue, and fundamentally changed the subscription commerce model. The open question cold email was the first move.

Groove HQ: Alex Turnbull emailed hundreds of SaaS founders about customer support

Before building Groove, Alex Turnbull had a hypothesis: SaaS founders were unhappy with their customer support tools. He didn't build first. He emailed first. Hundreds of cold emails to SaaS founders asking two questions: what customer support tool do you use, and what's the one thing you hate most about it?

The answers were consistent: Zendesk was overkill for small SaaS companies, Help Scout was okay but limited, everyone wanted something simpler. The qualitative data from those cold emails shaped the entire Groove product roadmap. Groove reached $500K MRR and became one of the more durable bootstrapped SaaS businesses of its era.

Turnbull later documented this process publicly on the Groove blog, under the "building a SaaS from scratch" series that became one of the most-read founder blogs in the bootstrapper community. The cold email customer discovery wasn't incidental -- it was the product strategy.

Cal.com: Peer Richelsen found the gap before building

Cal.com's origin is a slightly different flavor of this story. Peer Richelsen wasn't emailing founders for ideas -- he was running a different company (Leanhire) and kept hitting the same wall: no good open source scheduling infrastructure existed. He searched "calendly open source" and got nothing.

Before building, he did reach out to founders in his network asking how they handled scheduling, whether self-hosting mattered to them, and what they'd pay for an open scheduling infrastructure. The feedback from those conversations convinced him the gap was real and that the open source angle was the right wedge. He launched Calendso (later rebranded to Cal.com) in 2021, raised $7.4M seed round, and turned it into one of the most-starred open source projects on GitHub.

The discovery method: talk to founders about infrastructure pain before writing a line of code.

Intercom: Des Traynor asked the question before building the product

Intercom's origin story is well documented. Before building, Des Traynor and Eoghan McCabe ran a design consultancy and kept noticing that their clients had terrible ways of talking to users inside their web apps. They weren't just observing this -- they were asking their clients directly: "How do you talk to users once they're inside your product? What do you wish you could do?"

The answers formed the original Intercom product. Not a ticketing system, not a live chat, but something in between: contextual messaging to users based on what they were doing. The open question came first. The product came second. Intercom is now valued at over $1B.

4. 3. Why Founders Answer Open Questions

If you email a founder asking for 30 minutes of their time to review your pitch deck, response rate is low. You're asking for something that costs them time and gives them mostly nothing. But if you email a founder asking what they would build next, something different happens.

1. Founders love thinking about ideas. Most successful founders have more ideas than they can ever execute. Being asked "what would you build?" activates the part of them that enjoys this -- it's not a chore, it's a fun question they'd have fun answering.
2. They already have the answer ready. An established founder in a space has thought about adjacent problems for years. When you ask what's missing, you're not making them do new work -- you're asking them to retrieve something they already know.
3. It's genuinely flattering. You're implicitly saying: "You've built something impressive. I think your judgment about what's next is worth asking about." That framing is different from "help me get rich." It treats them as a domain expert, not a resource.
4. There's no competition risk. Unlike asking a direct competitor "what would you build?", asking a founder who's built a successful product in an adjacent space poses no threat to them. Peer Richelsen is not going to build a COSS holding company because you asked him about it. He's focused on Cal.com.
5. Most people don't ask. Founders get hundreds of emails asking for investment, collaboration, jobs, advice, and intros. They get almost zero emails asking a thoughtful open question with no immediate ask attached. The open question stands out purely by being unusual.

5. 4. The Pattern Behind Every Success Story

Looking across all the real cases -- Zapier, PostHog, Groove, Birchbox, Cal.com, Intercom -- a consistent pattern emerges.

6. 5. Invented but Plausible: COSS Discovery Scenarios

These are not documented cases. They're constructed scenarios that are plausible given what we know about the founders involved, the spaces they operate in, and the gaps that exist in the commercial open source ecosystem. They're meant to illustrate what this strategy could look like applied to your specific context.

Scenario A: Emailing Peer Richelsen (Cal.com) about scheduling infrastructure

Imagine you email Peer Richelsen with something like: "I've been following the journey with Cal.com -- building scheduling infrastructure as an open core product seems like it worked because the underlying need was infrastructure, not a consumer product. If you were starting over in a different category, what would you pick? What's the scheduling-of-something that doesn't exist yet?"

Peer's likely honest answer based on what he's said publicly: "Developer availability tooling. Cal solves human scheduling, but API rate limit scheduling, job scheduling, webhook retry scheduling -- there's no developer-native scheduling infrastructure with an open source self-hosted option. Most devs hack it with cron jobs."

You have now potentially discovered a real gap -- an open source developer-facing job scheduling / workflow orchestration layer -- through one email. You can validate this against the existing players (Inngest, Trigger.dev, BullMQ) and decide whether there's still whitespace.

Scenario B: Emailing James Hawkins (PostHog) about product analytics gaps

PostHog has made a deliberate decision to stay developer-centric. They've explicitly said they won't go downmarket to non-technical users. That's a choice that leaves a gap. Email: "PostHog is clearly built for developers installing it themselves. You've written about the trade-off of staying dev-focused. What's the product analytics problem you've consciously decided not to solve that keeps showing up in support tickets?"

Plausible answer: "Business users -- the non-technical stakeholders who need to see PostHog data but can't query it. We get constant requests for a 'PostHog for business teams' layer -- pre-built dashboards, natural language querying, automated reporting -- and we keep saying no because it's not our buyer. But someone should build it, probably as a PostHog extension."

You've just found a potential product: an open source business intelligence layer that sits on top of PostHog's data API, built for non-technical stakeholders. First customers: companies already running PostHog.

Scenario C: Emailing Sid Sijbrandij (GitLab) about DevOps workflow pain

GitLab is one of the largest open core companies in the world. Sid has been public about what GitLab does and doesn't do. Email: "GitLab covers the full DevOps lifecycle but as a company you've obviously had to make hard choices about what to go deep on versus keep shallow. What's the DevOps problem that GitLab keeps getting asked about but intentionally doesn't solve?"

Plausible answer: "Developer environment parity. We have CI/CD but the problem of 'it works in CI, fails locally' is still completely unsolved in our product. We built Gitpod as a portfolio investment but we never went deep on this ourselves. The open source remote development environment space is still wide open."

This is plausible because Gitpod exists, Devpod exists, but neither has the GitLab integration story nailed. The gap is real.

Scenario D: Emailing Adam Stacoviak (Changelog) about developer media infrastructure

Changelog is a developer podcast network with open source at its core. They've built a lot of the media infrastructure themselves. Email: "You've been building developer-focused media for over a decade. What's the podcasting or media infrastructure problem that you've solved internally that you think every developer content creator needs but doesn't exist as a product?"

Plausible answer: "Episode intelligence. We know which topics perform, which guests drive subscriber growth, which moments make people click through -- but we built all of that ourselves. There's no podcast analytics product built for technical content creators with chapter-level performance data, topic clustering, and cross-episode trends. We'd probably pay for that."

You've found a potential niche B2B analytics product: podcast analytics for developer content creators with topic-level depth.

Scenario E: The Meta Case -- emailing someone about the COSS category itself

Email Joseph Jacks (OSS Capital, coined the COSS acronym): "You've invested in or followed dozens of commercial open source companies. When you look across the portfolio, what's the category of developer tooling that has a clear market need, no credible open source project, and the window is still open? What would you fund if someone with strong execution capability showed up tomorrow?"

This is arguably the highest-leverage cold email you could send in the COSS space. JJ has done the research for you across the entire landscape. One honest answer from him is worth more than 100 hours of independent market research.

7. 6. Target List: 20 Founders Worth Emailing for COSS / Developer Tools Ideas

These are real people who are accessible, have relevant knowledge, and have a track record of answering thoughtful questions from strangers. They're ranked roughly by expected idea signal quality and likelihood of response.

8. 7. Email Templates (Jason Levin Framework)

These follow Jason Levin's cold DM principles: under 5 sentences, question not pitch, specific public signal, casual tone, no ask in the first message. Levin went from $12/hr Home Depot to $25K/month by sending cold DMs -- the whole playbook is documented here. The rules that matter most for emails to founders:

• Never pitch in the first message. A question, not a sales email.
• Reference something specific they did publicly. "Saw your post about X" beats "I've been following you for a while."
• Under 5 sentences. Write like you're texting, not cover-lettering.
• Warm up with a comment first. Comment on their latest post the day before. When the email lands, your name isn't cold.
• Give yourself a platform. "I'm writing about COSS" / "I'm building in public" is a reason to reach out that isn't "I want to extract value from you."
• Each reply powers the next. After 5 conversations, your next email says "I've talked to 5 COSS founders about this." Different email entirely.

Template 1: Respond to a public signal

Use when: they just posted something on X or LinkedIn that hints at a gap, a frustration, or a product decision.

Subject: re: your post about [thing]

Hey [Name],

Saw your post about [specific thing they said]. Quick question: is [gap you inferred from it] something you consciously decided to leave unsolved, or just never had bandwidth for?

I'm exploring building something in that space and your take would be genuinely useful.

-- Alexis (alexisbouchez.com)

Why it works: you're responding to a signal, not cold-opening. They already wrote about this. You're just continuing a thought they started.

Template 2: The platform play ("I'm writing about this")

Use when: you want to contact someone who gets a lot of pitches and won't answer a vague "can I pick your brain." Levin's key insight: reporters get answers because they have a reason to reach out that isn't "I want something." You can borrow the same frame.

Subject: quick question for a COSS piece I'm writing

Hey [Name],

I'm writing about what makes certain categories ripe for the open-core model and which ones aren't -- Cal.com, PostHog, Plane are obvious cases. One thing I haven't found a good answer to: what's the category where the open source version should exist but doesn't yet?

Would love to quote you if you have a take.

-- Alexis (alexisbouchez.com)

Why it works: "would love to quote you" is irresistible to most people who have opinions. You're offering to feature their expertise, not asking them to do unpaid consulting.

Template 3: The "scope limit" question

Use when: the founder's product has obvious intentional limits -- they've stayed in a lane and you can name it. Levin's principle: respond to a signal of need. An intentional scope limit is a signal of unmet demand.

Hey [Name],

[Company] clearly does [core use case] really well and just as clearly doesn't do [adjacent thing]. I'm curious: is that a "we tried and it's hard" or a "not our buyer" decision?

I'm exploring building in that gap and want to understand the constraint before assuming it's wide open.

-- Alexis

Why it works: you're asking a question that reveals you've actually thought about their product. Most founders find this more interesting than flattery.

Template 4: After 5 conversations (the social proof version)

Use when: you've already talked to a handful of founders. Levin's principle: each success powers the next. Now you're not a random person asking a question -- you're someone who has been doing research.

Hey [Name],

I've been talking to COSS founders this week trying to map which developer tooling categories are still open for an open-core play. So far: [one-line summary of what you've heard]. Your take would round this out nicely -- you've been in this space longer than most.

What's your answer?

-- Alexis

Why it works: "I've been talking to founders" signals you're doing real work. "Your take would round this out" is genuine -- you're not pretending to have no agenda, you're being honest about what you're trying to figure out.

Template 5: The build-in-public angle

Use when: you are actually building something in public (which you are, with Palmframe and the journal). Levin used his 100-day build challenge as a natural "reason to reach out." Same logic applies here.

Hey [Name],

I'm doing a build-in-public thing -- documenting publicly what I explore before committing to a product. Right now I'm trying to figure out which developer tooling category most needs the open-core treatment and doesn't have it yet.

You've navigated this with [Company] -- which category would you pick if you were me?

-- Alexis (building in public at alexisbouchez.com)

Why it works: "build in public" is a frame founders respect. It signals you ship, not just think. It's also a reason to reach out that has nothing to do with asking for their time -- it's just one interesting question mid-research.

A note on format

Plain text. No HTML. No "I hope this finds you well." No subject line that sounds like a pitch ("Exciting opportunity" / "Quick question about a partnership"). Short subject lines that describe what the email actually is: "re: your post", "quick question", "COSS thing". Match the register of how they write publicly -- if they write casually on X, write casually. If they write long-form essays, you can write one or two more sentences. Never more than five.

9. 8. What to Do With the Answers

This is where most people fail. They ask the question, get a great answer, and then spend six months thinking about it. Here's the right process.

Triage the answer immediately

When you get a reply, read it once for the signal and once for the subtext. What did they name explicitly? What did they gesture at without saying? The explicit answer is usually "here's what I think the gap is." The subtext is often more useful: "here's why I didn't build it" (timing, team, market size, distribution difficulty).

Make a note of both. The subtext often contains the real constraint you'll need to solve.

Follow up with a second question

If the answer is interesting, reply within 24 hours with one follow-up question. Not five. One. Something like: "That's really interesting. Is the constraint there the distribution problem (how do you reach the buyer) or the technical problem (it's just hard to build), or both?"

A single focused follow-up question is much easier to answer than a list of questions. It shows you read their reply carefully, and it often extracts the most useful detail.

Triangulate across multiple founders

One founder's opinion is a data point. Three founder's opinions pointing at the same gap is a pattern. Send the same core question to 10 to 20 founders. Keep notes on which gaps come up more than once. Consistent signals across independent sources are your strongest validation signal before you build anything.

Then do one small concrete thing before your next email

Once you have a hypothesis from the conversations, do one concrete thing: build a landing page, write a GitHub README, post a Show HN with a prototype, or write a short analysis. Then you can email the same founders back with "I took your advice and did this -- does this look right to you?" Now they're invested. They've shaped what you're building. They're much more likely to share it, use it, or introduce you to someone.

Wade Foster at Zapier didn't just talk to Andrew Warner -- he built the integration. James Hawkins didn't just take the YC dinner conversation home -- he rewrote the product. The conversation is the input. The thing you build in response is the output. Both matter.

10. 9. Mistakes That Kill the Email Before It Lands

11. 10. Your Specific Case: Emailing Peer Richelsen

You mentioned something like: "Hey, I find your journey with Cal to be really impressive. If you were to start a commercial open source..." That's a good instinct. Here's how to sharpen it.

What makes Peer a particularly good target

Peer has been unusually open about the Cal.com journey: the origin story (built because "calendly open source" returned zero results), the business model (AGPL + enterprise license), the distribution mechanics (GitHub stars as validation, developer community as first users), and the constraints they ran into. He writes on X, he's done podcast interviews, and he answers questions from people who show genuine curiosity about the open source model.

More importantly: Peer's journey is adjacent to what you're exploring. He took a closed-source category (scheduling), built the open source version, and made it a business. You're thinking about doing the same thing in a different category. He's literally the person who has navigated the terrain you're about to enter.

The specific draft for Peer (Levin-style)

First: comment on his latest X post the day before you email. Something genuine -- not "great insight!" but an actual reaction. When the email lands, your name won't be completely cold.

Subject: the "calendly open source" gap

Hey Peer,

The origin story -- googled "calendly open source," found nothing, built the thing -- is the cleanest COSS thesis I've seen. Genuinely studying it.

Quick question: if you were running the same search today in a different category, which one do you think still returns zero results?

-- Alexis (alexisbouchez.com)

Why this version works better than the original draft

• 49 words. The original was 113. Levin's rule: under 5 sentences, write like you text. This is 4 sentences.
• The subject line is the hook. "The calendly open source gap" makes him immediately know what the email is about and that you've actually done research.
• No preamble. The original had a full paragraph of setup. This opens with the specific thing and moves straight to the question.
• The question is framed as his insight applied elsewhere, not "give me an idea." Big difference.
• Personal domain as social proof. Levin's principle: have something to show. alexisbouchez.com says "I build and publish things" without saying it.
• No pressure-release sentence. "You don't have to answer" signals insecurity. The short email already does the work of being easy to respond to.

What to do after

If he replies with a category name or a specific gap, your next move is to spend 48 hours doing market research on that category -- existing players, GitHub stars for any OSS alternatives, G2 reviews, pricing. Then reply with: "Really interesting. I looked at [category] -- seems like the closest thing is [existing product] but [gap you found]. Does that match what you were thinking, or am I missing something?"

Now you're in a dialogue. You're not asking him to do your research. You did the research and you're asking for a sanity check. That's a much easier thing for him to respond to, and it signals you're serious.

12. 10b. Draft: Guillaume Moubèche (Lemlist)

Guillaume is the founder of Lemlist -- 40M+ ARR, bootstrapped, never raised a euro of external capital. He recently stepped back as CEO and is now Chairman, plus an investor in ~25 companies. He just did an episode of "Le nerf de la guerre" where he talked about his bootstrap philosophy, why he went without a finance function for years, and how a part-time CFO was ROI-positive in one week by renegotiating Stripe fees.

The signal: that episode. The hook: he said his focus was always the top line, never cost optimization. He's a builder who started from nothing (immigrant grandparents, no money, debt = stress) and built something worth $150M+ without asking anyone for money.

Sujet : le prochain Clap

Hey Guillaume,

Vu ton épisode sur Le nerf de la guerre -- Clap était évident pour les utilisateurs lemlist. C'est quoi le prochain outil dans cette logique qui n'existe pas encore ?

-- Alexis (alexisbouchez.com)

20 mots. Centré sur l'acquisition de Clap qu'il vient de faire -- signal public récent, pas générique. La question découle directement de sa propre logique ("évident pour les utilisateurs"). Pas de setup, pas de pont forcé, pas de pitch. Juste la question.

13. 11. Verdict

The cold email to founders for idea discovery is underused because it requires you to be in an uncomfortable position: you have nothing to show yet, you're asking for help, and you might feel like you're wasting their time. All of those feelings are wrong.

Founders of successful products have surplus insight into their category's gaps. They can't act on everything they know. A thoughtful email that asks the right open question is genuinely interesting to answer -- it costs them almost nothing and it might set someone else on a useful path. Most of them like that idea.

The Zapier story matters because Wade Foster didn't wait until he had something built to reach out to Andrew Warner. He reached out, built fast, and converted the conversation into a customer. The PostHog story matters because James Hawkins didn't just take notes from the YC dinner conversation -- he went home and rewrote the product.

The strategy only works if you do something with the answers. Conversations without action are just interesting. Conversations that lead to shipping are how companies start.

The minimum viable version of this strategy

1. Pick five founders from the target list above. One of them is Peer Richelsen.
2. Write five individual emails using the templates above, customized with one specific reference for each founder.
3. Send all five in the same week.
4. Take the best answer you get and do one concrete thing with it in the following 7 days: a GitHub README, a landing page, a Show HN post, or a short analysis posted publicly.
5. Reply to the founder with what you built. Watch what happens next.

Five emails. One week. One thing built. That's the whole playbook.