The Devtool Design-Partner Playbook: Issue-Tracker Pain to Signed Partners

This playbook is for technical founders and developer-relations leads who need three to five design partners for a developer tool and want them sourced from public engineering evidence, not only from a warm network. It takes a one-line problem statement through issue and patch harvesting, employer resolution, authority mapping, and outreach, all the way to signed agreements. You come out with a target long-list size, conversion benchmarks for each stage, and a dated log of every account you dropped and why.

A design partner, for this guide, is an external team that agrees to use an early version of your tool and give structured feedback on a fixed cadence, usually under a short written agreement.

What numbers should a design-partner slate plan against?

Plan for 3 to 5 signed partners, 30 to 50 initial conversations, and about one signed partner for every ten conversations. These are Allston Labs' planning figures, and they are the most specific published funnel to schedule against.

Allston Labs gives the pipeline as 30 conversations, then 8 qualified, then 3 signed, with about 38% of qualified prospects signing. Its planning inputs are a target signed count (typically 3 to 5) and a target conversation count derived from the funnel (typically 30 to 50). For a sense of what a full slate looks like, Sierra set out to sign four design partners and ended with six, all of whom were also paying customers, held to weekly 30-minute standups.

The source of each conversation moves the math more than anything else. The two published sources measure different things: Koji reports how often a source accepts a design-partner ask, and Allston Labs reports how often a conversation from that source qualifies.

Koji does not publish how it measured these, so treat them as ranges, not targets you can hold a team to. The evidence-led channel in this playbook is cold outbound with a specific reason attached. Allston Labs reports that founders whose only ask is "would you be a design partner?" get reply rates under 1%. It also reports that asks tied to a specific case convert at 3 to 5 times the rate of cold "want to chat?" emails. Nobody has published whether citing a GitHub issue or patch improves acceptance, so plan at cold rates and treat any lift as upside.

Long-list size

At 1 to 3% cold acceptance, three signed partners need 100 to 300 cold contacts. In practice:

• Rank at least the top 100 authors before you send anything.
• Keep the rest of the harvest as a refill queue, already scored.
• If warm introductions cover part of the slate, the evidence list only has to cover the gap.

Cycle length

The published figure is one to three months from first conversation to signed agreement for SMB and startups under 100 employees. No one has published separate figures for individual developers or for enterprises going through procurement and security review. If your best evidence sits inside large companies, assume a longer cycle and track your own dates per stage.

Where this sits next to the warm network

Sources disagree on order. Allston Labs puts 20 to 40 discovery conversations before recruitment begins, and Koji puts the warm network first, with cold outreach as a backstop. I run the evidence channel alongside warm introductions, not after them, because the harvest also shows which warm contacts actually have the problem.

Which public artifacts prove a team feels the problem?

Five kinds of artifact on incumbent and adjacent repositories carry dated proof of pain: reacted issues, issues closed as not planned, workaround forks, vendored patches, and discussion comments. Each proves something different, and each has its own way of misleading you.

An incumbent repository is the project your tool replaces or wraps. An adjacent repository is a library or integration that users combine with the incumbent, where the pain often surfaces first. A vendored patch is a modified copy of a dependency checked into a team's own codebase so they can ship a fix the upstream project has not merged.

My own ranking puts a maintained fork or vendored patch above a +1, because it shows a team spent engineering time living with the problem. That is judgement, not published evidence. No study links any of these artifacts to whether a team accepts a design-partner ask, so tag every lead with the artifact it came from and check at the end which artifacts produced signatures.

How do you harvest issues and patches without hitting the search caps?

Run issue and code searches per repository with date filters, and split any query that reaches 1,000 results into narrower date ranges until every slice comes back under the cap. Budget one to two days, because the search API's rate limit sets the pace.

These are the issue search qualifiers that matter, from GitHub's documentation on searching issues and pull requests:

• reactions:n filters by reaction count.
• interactions:n filters by reactions plus comments.
• created: and updated: take date ranges.
• is:closed reason:"not planned" isolates issues the maintainers declined.
• sort:reactions-+1 orders by thumbs-up count.

These are the limits that shape the harvest:

• Each search returns up to 1,000 results, at a maximum of 100 per page.
• Search endpoints allow 30 requests per minute. Code search requires authentication and allows 10 requests per minute.
• Code search queries are capped at 256 characters and exclude forks unless you add fork:true.

A full 1,000-result slice is 10 pages. At 10 code-search requests per minute, every full code-search slice costs at least a minute. Issue search is three times faster, but a dozen repositories with several queries each still adds up to hours, not minutes.

GitHub documents the 1,000-result cap but no procedure for working around it. Splitting by date range until every slice returns fewer than 1,000 results is practitioner convention. If a slice returns exactly 1,000 results, or the final page comes back full, split it again.

Two tools widen the net. The gh search issues command supports --search-type semantic, which catches issues that describe your problem without using your keyword. Check that your installed version supports it. For forks, the CHAOSS data science working group publishes a fork case-study script you can adapt to list an incumbent's forks and check which ones carry their own commits.

is:issue repo:OWNER/REPO "KEYWORD" updated:YYYY-MM-DD..YYYY-MM-DD reactions:>=10 sort:reactions-+1
is:issue repo:OWNER/REPO "KEYWORD" updated:YYYY-MM-DD..YYYY-MM-DD interactions:>=20
is:issue repo:OWNER/REPO is:closed reason:"not planned" "KEYWORD" updated:YYYY-MM-DD..YYYY-MM-DD
is:issue repo:OWNER/REPO is:closed -reason:completed -reason:"not planned" "KEYWORD" updated:YYYY-MM-DD..YYYY-MM-DD
gh search issues "plain-English description of the problem" --repo OWNER/REPO --search-type semantic
"PACKAGE_NAME" path:vendor fork:true

The fourth line is a separate pass for duplicate closures, which match neither reason:completed nor reason:"not planned". Spot-check its results in the web interface before you rely on it.

The harvest is done when you have one deduplicated table with these columns: evidence URL, artifact type, repository, author handle, created date, last-updated date, reactions, interactions, and close reason.

How do you resolve an author to an employer and a signer?

Resolve employers in a fixed order: commit email domain, then the profile company field, then a manual check. Record each employer with a date and a confidence level. Then find the manager or director above that engineer, because the person who filed the issue is rarely the person who can sign.

Employer resolution order

1. Commit email domain. Researchers consider this the most accurate source of affiliation data. It only exists if the author has committed somewhere public. In one study, 71.0% of committers' email addresses could be linked to a GitHub account, so the join between commits and accounts is good but not complete.
2. Profile company field. This is free text with no date attached. Normalise variants such as @elastic, Elastic, and Elastic Inc, and assume it may name a past employer until a recent commit domain agrees.
3. Manual check. Expect this to take up to 10 minutes per contributor. For 100 authors, that is up to two working days.

Accuracy varies a lot by project. An automated pipeline that combined commit email domain with the profile company field produced these results:

The likely cause is that community-heavy repositories have more contributors using personal email addresses, which tell you nothing about employer. No one has published resolution rates for issue authors specifically, or false-match rates broken out by method. Issue authors who have never committed have no commit email at all, so expect to do worse than the commit-author figures above. Check locally: resolve 20 authors by hand, compare your automated result against them, and use the match rate to decide how much manual time to budget.

Give every row a confidence level:

• High: a recent commit email domain and the company field name the same employer.
• Medium: one source names the employer and the evidence is inside your recency window.
• Low: manual inference only, or the sources disagree.

Only high and medium rows go to outreach. Low rows stay in the refill queue until something corroborates them. This is where Refolk saves the most time: I resolve a GitHub author to a current, dated employer and role from the public GitHub graph and public professional records, so the 10-minute manual check becomes a confirmation rather than an investigation.

Mapping authority

The issue author proves the pain. The signer is usually one or two levels above them. In Refolk's index of professional profiles, the decision-maker pool for one common devtool buyer is larger than the practitioner pool:

The employer lists come from a 25-profile sample of each segment. Two things follow from the table. The US practitioner pool is 2.92 times the German one, so a Germany-only slate draws from a much smaller set of authors. More importantly, managers outnumber the engineers who file the issues.

An issue author proves the pain. Only someone above them can sign for the fix.

For each account, identify the engineering manager, director, or head of platform who owns the team the author sits on. Treat the author as your champion and the manager as your signer. Mapping is done when every account on the list has one named person who can say yes, or the account is logged as disqualified with a reason. Refolk handles this join directly: ask for the leaders at companies whose engineers hit the problem, and the authors and their managers come back together.

How do you score pain and authority?

Score each account on two axes: how acute and current the pain is, and how close your named contact is to a signature. Work the high-pain, high-authority quadrant first. No published scoring rubric exists for the pain side, so treat the one below as a starting point and adjust it against who actually signs.

Pain signals, roughly in order of weight:

• Recency (required): the evidence was created or updated inside your window, for example the last 12 months. Anything older is disqualified, not down-weighted.
• Investment: the account maintains a fork or a vendored patch for the problem.
• Refusal: the issue was closed as not planned, or as a duplicate of one that was.
• Breadth: high reactions or interactions on the issue.
• Repetition: several engineers at the same employer show up across different artifacts.

Authority levels:

• Named signer: an engineering manager, director, or head of platform is identified and their employer is confirmed.
• Influencer: a staff engineer or tech lead with a credible say in tooling is identified.
• Author only: you have the engineer who filed the issue and nobody above them.

The step-by-step procedure

Run these eight steps in order. The first five take about a working week for one person. Outreach takes two to four weeks, and signing takes one to three months for smaller companies.

Qualification criteria

A conversation qualifies when all four of these hold:

• The pain is current and the team has not already solved it in a way they are happy with.
• A named person with authority to sign is in the conversation or has agreed to join.
• The team will commit to a feedback cadence. Sierra ran weekly 30-minute standups.
• They want the problem solved, not a new toy. Sierra screened out prospects who were "interested in 'playing with AI'". The devtool version is a team that wants to try your tool but has no deadline attached to the pain.

Agreement terms

The Common Paper Design Partner Agreement, published under CC BY 4.0, is a sensible starting template. It includes a fill-in field to "Participate in [ # ] Feedback sessions per [ month | quarter | year | term ]" and states "Provider owns all Feedback." Other terms to set:

• Duration: many programs run for 60, 90, or 180 days.
• Pricing: one documented model is free in the design phase with a locked discount once the product is paid. Sierra's partners were all paying.
• Exit: one documented model lets either side leave on 30 days' notice.

Bring in counsel when the deal involves sensitive data, regulated workflows, exclusivity, procurement, or material revenue. One law firm warns that feedback-assignment language may imply the startup can use partner input for model training. If that is not your intent, say so in the agreement. Which terms most often stall a signature is not established publicly, so log the clause and the date every time a partner pushes back.

The week-three read

By the end of week three of outreach, divide booked conversations by ten. That is your projected signed count at the published rate of about one signed partner per ten conversations. If it projects under three, pull scored accounts from the refill queue or add an adjacent repository to the harvest now, not at week six.

How do you reach out without breaching GitHub policy or GDPR?

Every first message must say who you are, which public GitHub record led you to them, why you are writing, the legitimate interest you rely on, how long you will keep their data, and how to object. If they object, stop. This is a working summary of the published rules, not legal advice. Have counsel review your notice once before you send at volume.

GitHub's Acceptable Use Policies say: "If you collect any personal information from the Service, you agree that you will only use that personal information for the purpose for which that User has authorized it." The same policy says "Scraping does not refer to the collection of information through our API." Copies of the same policy wording republished by other sites forbid using the data for "sending unsolicited emails to users." Read the current wording on GitHub directly before you start, because policies change and copies go stale.

The practical consequence: use GitHub to find the pain and the employer, not to collect email addresses for cold email. Reach the signer through professional channels, and cite the public evidence as the reason you are writing.

Under GDPR Article 14, when you did not collect the data from the person directly, the notice is due "within one month of obtaining the data, or at the latest at the first communication if the data will be used to contact them, whichever comes first." It must cover who you are, the purpose, the legal basis, the legitimate interest you rely on, where the data came from, and how long you intend to keep it. The UK ICO's guidance on the right to be informed sets out the same elements. On objections, Sweden's regulator (IMY) says you must always stop direct marketing once the person objects.

Subject: The OWNER/REPO #NUMBER workaround your team is carrying

Hi FIRST_NAME,

I'm NAME, founder of COMPANY. Engineers on your team commented on OWNER/REPO #NUMBER, which was closed as not planned, and your org appears to maintain a patched copy to work around it.

I'm building TOOL to remove exactly that workaround. I'm looking for three to five teams to shape the first version: a 30-minute session every two weeks for 90 days, free during the design phase.

Would it be worth 20 minutes to see whether it fits your case?

NAME

Why you're getting this: I found the public GitHub record above and identified you as the engineering lead for that team from public professional records. I'm contacting you for the legitimate interest of recruiting design partners for TOOL. I keep your name, role, employer, and the source link for RETENTION_PERIOD, then delete them. Reply "no thanks" and I will not contact you again.

How this goes wrong: failure modes and false positives

Most failures in this playbook look like success until outreach: a long, well-sorted list made up of stale pain, wrong employers, and people who cannot sign. These are the eight to check for, what each looks like, and the fix.

1. Stale reaction counts. An issue with hundreds of +1s tops the list, but most of the reactions are years old and the people who left them have moved on. Reactions accumulate over an issue's lifetime. Fix: require an updated: date inside your window, and check the date of the latest comment, not just the issue's creation date.
2. Duplicates missing from the not-planned pass. Your not-planned query looks complete, but every issue the maintainers closed as a duplicate is missing. A duplicate closure matches neither reason:completed nor reason:"not planned", so a two-bucket query drops it without warning. Fix: run the separate duplicate pass from the harvest template.
3. A wrong or stale company field. The profile says one employer, but the person left a year ago, or the same employer appears three ways. The company field is free text with no date. Fix: normalise variants, and require a recent commit email domain to agree before you mark a row high confidence.
4. An acquired commit domain. The commit email domain points to a company that no longer exists on its own because it was acquired. The Cassandra project health work had to date its domain map, for example mapping DataStax addresses to IBM from the acquisition date. Fix: keep a dated domain-to-employer map and check acquisitions for any domain that resolves several authors.
5. Silent truncation at 1,000 results. A slice returns exactly 1,000 results and the last page is full, so you never see what was cut off. Fix: treat any full final page as truncated and split the date range again.
6. Author mistaken for buyer. Outreach goes to the engineer who filed the issue. They agree enthusiastically and then cannot get anyone to sign. Fix: no account goes to outreach without a named signer from the authority-mapping step. The Refolk index figures above show the signer pool is larger than the author pool, so the signer is usually there to be found.
7. An experimenter posing as a design partner. The team is keen, books every session, and has no deadline attached to the pain. That is a free pilot, not a design partnership. Sierra screened out prospects "interested in 'playing with AI'". Fix: ask what happens if the problem is still unsolved in a quarter, and disqualify teams with no answer.
8. A non-compliant first message. The first email cites the issue but leaves out the notice. Under Article 14, the notice is due at the first communication at the latest, so the breach happens on the first send. Fix: put the notice block in the template itself, not in a follow-up.

One more limit to be honest about: everything in the artifact and scoring sections is a reasoned hypothesis. Nobody has published which artifacts predict acceptance, so your own log becomes the best evidence you have after one slate.

How do you keep the slate and disqualification log current?

Keep one log with a dated row for every account you dropped at any stage. Re-resolve employers before every send and review the log at the end of each slate. The log is what makes the second slate faster than the first.

Each disqualification row needs these fields:

date | account | author handle | signer (if any) | evidence URL | artifact type | stage dropped | reason code | re-check date

Use a short, fixed list of reason codes so you can count them: stale evidence, unresolved employer, no signer found, objection, experimenter, timing, terms. Set a re-check date on every "timing" or "no signer found" row. Those are the accounts most likely to become partners the second time round.

Employer data decays. Re-resolve any row whose employer date is older than the outreach window before you send to it. At the end of each slate, count signed partners by artifact type and by source. That count is the local evidence that replaces the hypotheses in this guide.