Recruiting Design Partners for a Developer Tool From Public Signals

You are building a 0-1 developer tool and you need three to six design partners who genuinely feel the pain you are solving, not whoever your network happens to know. This guide is for technical founders, engineering managers, developer-relations leads, and technical sourcers. It takes you from a written pain profile to a ranked list of companies and the named engineer inside each who owns that pain, ready to invite into a time-boxed program.

Most published advice stops at "profile the pain and mine your warm network." That is where the real work starts, not where it ends. A warm network gives you people who will take your call, which is not the same as people who feel your problem this week. This guide shows you how to locate the companies whose public stack, repositories, and issue activity prove they feel the pain now, and how to resolve each one down to the specific engineer.

Who a design partner actually is, and how many you need

A design partner is a co-builder who feels your pain now and will adopt an unfinished product, not an advisor who already solved the problem and lends judgment. Recruit for acute current pain and the authority to adopt, not for a resume.

The number question has a clear answer once you read the sources side by side. No single figure is canonical, but the named practitioners cluster tightly. The working target for a 0-1 developer tool is three to six deeply engaged partners: enough to spot real patterns across users, few enough that each one gets the attention that produces high-quality signal.

Two things anchor the band. The floor is two, not one: Barry's contrarian read is that a single design partner is bad because you overfit your roadmap to one voice, so the smallest defensible number is two. The ceiling comes from attention. Bessemer runs higher at five to twelve because they optimize for pattern coverage across an ICP, while Mika Reyes deliberately aims lower, at three to five deep paid partnerships out of roughly 150 to 200 conversations. If you are pre-launch and building alone, treat three to six as the target and let the pain skew you toward the low end.

On duration, the clearest published figure is six to twelve weeks of active collaboration, which is enough to ship iterations and validate the outcome. That is a program with a start and an end, not an open-ended relationship.

Turn the pain into public signals you can search

A public signal is anything visible from outside a company that proves it feels your pain: a package dependency, an open issue, a commit pattern, or a job posting that discloses the stack. Before you touch a search box, write the pain profile down.

Get precise about the profile before outreach. One page: the acute pain, the stack that produces it, and the role that owns it. If it is not written, you will drift toward whoever replies fastest, which is how you end up with an enthusiastic non-buyer who loves the demo and never adopts.

Then translate each pain into a signal you can actually query. The mapping is the whole method:

• Dependency pain: they depend on the package your tool replaces or extends. Signal: GitHub's dependency graph Dependents view, plus code and package search.
• Workaround pain: they have hacked around the problem with scripts or a rival tool. Signal: open issues, README notes, and public gists that describe the workaround.
• Hiring pain: they are staffing against the problem. Signal: job postings naming the specific technology.
• Community pain: they are vocal about an adjacent tool. Signal: who stars, watches, or files issues on that tool.

The dependency graph is the workhorse. For public repositories, the graph lists dependents, meaning other public repositories that depend on the repository or on packages it publishes. That is the closest thing to a public "who uses this" index that exists.

That blind spot is not a nuisance, it is a bias you have to correct for deliberately. If your longlist is 100 percent open-source-heavy startups, your feedback will generalize to open-source-heavy startups and nowhere else. The representativeness screen later in this guide exists partly to catch this.

Build the company longlist from dependents

The longlist is 20 to 40 companies whose public work proves they touch your pain. You build it from the outside in: start with the packages and tools your pain profile named, then find who depends on them.

Work down three layers, widest first, and stop when you have enough.

Layer one is the dependency graph. Open the Dependents view on the package your tool competes with or complements, and read off the public repos that import it. Two open-source helpers extend this: package-adoption finds where a JS or TS package is used across a GitHub org, and jabbar aggregates the orgs and affiliations of people who star or watch a repo. Both turn raw repo lists into company signals.

Layer two is code and package search, which catches imports the dependency graph misses because they are not declared as formal dependencies.

Layer three is job postings and conference talks, which is where you recover the private-stack companies the graph never shows you.

The reason this longlist step matters more than the outreach step is scarcity. Your ceiling is set by how many qualified engineers exist, not by your method.

Both rows are US SRE and platform engineers from Refolk's index. If your pain is defined by a common skill like Kubernetes, a 40-company longlist is easy and you can afford to be selective. If it is defined by something rare like OpenTelemetry, where the qualified pool is 52 times smaller, a 40-company longlist is impossible and the three-to-six advice inverts into "recruit every qualified engineer you can find." Know which regime you are in before you promise yourself a shortlist.

Geography multiplies the same funnel math. US Rust supply is 4.95 times German supply, so a founder recruiting from Germany alone draws the same 150-to-200-conversation funnel from a fifth of the pool.

Both rows are senior and staff software engineers with Rust from Refolk's index. The lesson is not that Germany is a bad market. It is that if your pain lives in a scarce skill, cross-border sourcing is a requirement, not a nicety. This is exactly the kind of resolution Refolk is built for: you describe the engineer and the pain in plain English and get back named people across GitHub, LinkedIn, and the open web, which collapses the longlist-to-shortlist gap that eats a founder's week.

Resolve each company to the one engineer who owns the pain

A company is not a design partner; a person is. For each company on the longlist, resolve to a single named engineer with a profile URL, and confirm they own the pain-relevant work rather than merely appearing in a contributor count.

The procedure is documented and repeatable. Open the repository's Insights then Contributors view, where you can view the top 100 contributors; merge commits and empty commits are not counted. Then narrow with commit search, since you can find commits by a particular user with the author or committer qualifiers, and the author-name and committer-name qualifiers match commits by name. Finally, cross-reference the company team or about page and the engineer's profile affiliation to confirm the employer.

Total count is a weak proxy for ownership. What proves ownership is whether the person's commits are recent and whether they touch the files that produce your pain. A top-line committer might have landed one big refactor two years ago; the person who owns the pain today may be lower on the count but active in the exact module you care about.

There is a silent trap in the contributor UI. GitHub links only the first 500 author email addresses to GitHub users; the rest appear as anonymous contributors. On a large repo, the exact senior engineer who owns your pain can be invisible in the contributor list. When that happens, resolution has to fall back to commit-email domains: read the email domain on the relevant commits and match it to the company, then find the person through their profile or the company directory. The same limit means the contributors graph itself is only available on repos with fewer than 10,000 commits, so on very large projects you work from commit search directly.

Score and rank on urgency, capability, and representativeness

The canonical scoring framework is a16z's three-part model: urgency, capability, and representativeness. It exists to stop you wasting time with unimpactful partners who give misleading feedback or use the product the wrong way. Score every shortlist candidate on all three, then add two operational screens.

The load-bearing screen is acute current pain: they feel the problem now and have already tried to solve it with spreadsheets, scripts, or a rival tool. A candidate who has built a workaround has proven the pain is real with their own time. Add representativeness so their feedback generalizes, then the operational sub-dimensions: willing to invest time, candid rather than polite, and with some authority to act, meaning they can adopt the tool and later sign off on paying for it.

Mika Reyes compresses this into a three-question screen you can run in one call:

• Do they have a real problem with business impact, versus "wouldn't it be cool"?
• Are they willing to give feedback regularly?
• Could they be a good reference for future customers?

Score each candidate 1 to 3 on urgency, capability, and representativeness, then flag authority as a hard gate. Anyone who fails the authority gate drops off the shortlist regardless of score, because feedback from someone who cannot adopt is feedback you cannot act on. Rank the survivors and take your top 8 to 12 into outreach, expecting to convert three to six.

A candidate who already built a workaround has proven the pain with their own time. That is the strongest signal on the page.

How this goes wrong: the failure modes

Every failure mode here is a false positive, a signal that looks like fit and is not. This section is the most valuable part of the method, because a design-partner program that overfits or fills with non-buyers is worse than one that recruits slowly.

• The empty Dependents view. You see thin dependents and conclude nobody feels the pain. Real cause: the target's usage is in private repos, which the graph never reports. Check job postings and public conference talks before you give up on a whole segment.
• The drive-by contributor. A top committer looks like the pain-owner but isn't; they may be a one-time contributor or a bot. Check commit recency and whether the commits touch the pain-relevant files, not just total count.
• The anonymous owner. Only the first 500 author emails resolve to users, so a key engineer appears as an anonymous contributor. Cross-reference the commit email domain with the company instead of trusting the graph UI.
• The enthusiastic non-buyer. A candid, eager engineer with no authority. The tell is high call attendance and zero adoption. Confirm they can adopt the tool and later sign off on paying for it before you commit a slot.
• The non-representative super-user. They solve the pain in an idiosyncratic way and pull your roadmap toward an edge case. Check the pain generalizes across at least two other longlist companies before committing.
• The vitamin, not the painkiller. The problem is a nice-to-have. The tell is a warm reply with no urgency. Screen with the business-impact question: a real problem with impact, not "wouldn't it be cool."
• The over-long sequence. Ten or more touches degrade reply rate and read as spam. Cap at about five and add a second channel instead.
• Too few partners. One voice overfits. The two-partner floor exists precisely because one design partner risks overfitting your roadmap.

The representativeness failure and the private-repo failure are linked, and worth reading together. Because dependents are not reported for private repositories, dependency-graph sourcing pulls you toward open-source-heavy companies, which are frequently the ones least able to pay. That is a structural bias in your longlist, and the a16z representativeness dimension is exactly the check meant to catch it. If your whole cohort is public-repo startups, your feedback will not generalize to the enterprises you eventually want as customers.

Run the outreach and confirm the program

Outreach for design partners is short, personalized, and multichannel, not a long drip. The goal is three to six acceptances from your 8-to-12 shortlist over two to three weeks.

Authenticity matters more than polish. Founders receive dozens of emails daily, so yours needs genuine interest, not transactional intent. The documented structure: open with a specific observation about the recipient, state who you are in one sentence, make one time-boxed ask, and include a graceful exit ramp. Emails under 120 words tend to outperform.

title: First-touch design-partner email
note: Replace the bracketed observation with the exact public signal you found. Keep it under 120 words.
Subject: your OpenTelemetry collector issue

Hi Priya,

I saw your issue on the collector's batch-processor memory growth, and the workaround you posted. I am building a tool that targets exactly that failure mode.

I am running a 6-week design-partner program with three to six engineers who feel this pain now. It is a 45-minute setup call, then a short check-in every two weeks.

Would you be open to a 20-minute call to see if it fits? If the timing is wrong, no problem at all, and thank you for the public write-up either way.

- Sam