Developer GTM (Selling to Developers) skill

Build a developer go-to-market motion the way Vercel, Stripe, and Twilio do — open-source/framework flywheel, docs and quickstarts as the funnel, transparent self-serve pricing, PQL signals, DevRel/community as distribution, and a sales motion that enables developer champions instead of cold-pitching them.

by LeadMagic·MIT license·★ 62 Stars on the repo·GitHub ↗

Use now

Inside this skill

SKILL.md · the author's own words

# Developer GTM (Selling to Developers)

## Overview

Developer go-to-market fails when teams run a generic B2B playbook at a
technical buyer: gated whitepapers, "request a demo" walls, cold SDR sequences,
and pricing hidden behind a sales call. Developers evaluate by building, not by
sitting through pitches — and they route around anything that feels like
marketing. This skill encodes the motion used by developer-first companies
(Vercel, Stripe, Twilio): earn trust by helping developers ship, let the
product and docs do the selling, then bring sales in to enable the champion and
close the economic buyer — never to pitch the developer.

The mistake this prevents: treating developers as leads to be worked instead of
builders to be unblocked, and confusing bottom-up adoption (the developer) with
the top-down purchase (the economic buyer).

Word-for-word excerpt, not a result. Read the full SKILL.md ↓

Discussion

Alternatives

API and interface designGuides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.Coding · MIT Context7Pulls up-to-date, version-specific library docs and code examples into the prompt so the AI stops inventing old APIs.Coding · MIT Context7 Documentation LookupFetch up-to-date documentation and code examples for any library, framework, SDK, CLI tool, or cloud service. Use whenever the user asks about a specific library — even well-known ones like React, Next.js, Prisma, Express, Tailwind, Django, or Spring Boot — because training data may not reflect recent API changes or version updates. Always use for: API syntax questions, configuration options, version migration issues, "how do I" questions mentioning a library name, debugging that involves library-specific behavior, setup instructions, and CLI tool usage. Use even when you think you know the answer. Do not rely on training data for API details, signatures, or configuration options — they are frequently out of date. Prefer this over web search for library documentation.Coding · MIT Adaptyv Bio Foundry APIHow to use the Adaptyv Bio Foundry API and Python SDK for protein experiment design, submission, and results retrieval. Use this skill whenever the user mentions Adaptyv, Foundry API, protein binding assays, protein screening experiments, BLI/SPR assays, thermostability assays, or wants to submit protein sequences for experimental characterization. Also trigger when code imports `adaptyv`, `adaptyv_sdk`, or `FoundryClient`, or references `foundry-api-public.adaptyvbio.com`.Science · MIT

Browse more free Claude skills or everything in Development.

1	---
2	name: developer-gtm
3	description: >-
4	Build a developer go-to-market motion the way Vercel, Stripe, and Twilio do —
5	open-source/framework flywheel, docs and quickstarts as the funnel, transparent
6	self-serve pricing, PQL signals, DevRel/community as distribution, and a
7	sales motion that enables developer champions instead of cold-pitching them.
8	Use when designing GTM for a developer tool, API, or infrastructure product,
9	or when sales feels like it is fighting the buyer. Triggers on: "developer
10	selling", "sell to developers", "developer GTM", "DevRel", "developer
11	marketing", "open source GTM", "Vercel GTM", "bottom-up developer adoption",
12	"API product GTM", "PLG for dev tools".
13	license: MIT
14	compatibility: Claude Code, Codex, GitHub Copilot, Cursor, Gemini CLI, OpenCode, Goose, Hermes, Windsurf, Zed
15	metadata:
16	version: "1.0.0"
17	author: LeadMagic
18	category: product-led-growth
19	tags: [developer-gtm, devrel, developer-marketing, open-source, plg, self-serve]
20	related_skills: [plg-strategy, freemium-optimization, founder-brand, content-led-growth]
21	frameworks:
22	- "Guillermo Rauch (Vercel) — Framework-defined infrastructure & DX-led growth flywheel"
23	- "James Allgrove (Stripe) — Self-serve signup + build-with-developers sales motion"
24	- "Adam DuVander (EveryDeveloper) — Developer Marketing Does Not Exist (education over promotion)"
25	- "Lee Robinson (ex-Vercel VP DX, now Cursor VP Developer Education) — Docs, education, community as distribution"
26	- "Wes Bush / Elena Verna (ProductLed / Reforge) — PQL signals + product-led + sales-assist hybrid"
27	---
28
29	# Developer GTM (Selling to Developers)
30
31	## Overview
32
33	Developer go-to-market fails when teams run a generic B2B playbook at a
34	technical buyer: gated whitepapers, "request a demo" walls, cold SDR sequences,
35	and pricing hidden behind a sales call. Developers evaluate by building, not by
36	sitting through pitches — and they route around anything that feels like
37	marketing. This skill encodes the motion used by developer-first companies
38	(Vercel, Stripe, Twilio): earn trust by helping developers ship, let the
39	product and docs do the selling, then bring sales in to enable the champion and
40	close the economic buyer — never to pitch the developer.
41
42	The mistake this prevents: treating developers as leads to be worked instead of
43	builders to be unblocked, and confusing bottom-up adoption (the developer) with
44	the top-down purchase (the economic buyer).
45
46	## When to Use
47
48	- "How do we sell to developers without annoying them?"
49	- "Design GTM for our API / dev tool / infrastructure product"
50	- "Build a developer marketing or DevRel function"
51	- "Open-source flywheel — how do we monetize it like Next.js → Vercel?"
52	- "Set up a self-serve free tier that feeds enterprise sales"
53	- "Our SDRs are cold-calling developers and it's backfiring"
54	- "When should sales engage a bottom-up account?"
55
56	## Authoritative Foundations
57
58	- Guillermo Rauch (Vercel founder/CEO, creator of Next.js). Vercel's wedge
59	is developer experience: the open-source framework (Next.js) is free and
60	self-hostable, and "framework-defined infrastructure" makes deploying to
61	Vercel the path of least resistance. Self-serve (Hobby/Pro) drives adoption;
62	enterprise sales arrives later because viral framework usage pulls it in. On
63	the WorkOS podcast Rauch frames both DX and enterprise as priorities —
64	developers are the advocates inside enterprise deals. Full case →
65	`references/vercel-developer-selling.md`.
66	- James Allgrove (Stripe). "How Stripe Built a Sales Organization to
67	Successfully Sell to Developers": instant self-serve signup and API keys, no
68	forced contract or sales call, "build with them, not talk at them," and a
69	sales job that unblocks developers and helps them make the internal case.
70	- *Adam DuVander (EveryDeveloper) — Developer Marketing Does Not Exist.*
71	Marketing to developers should be invisible: education over promotion,
72	specific not generic, with docs, tutorials, guides, open source, and tools as
73	the marketing surface. Never waste a developer's time.
74	- **Lee Robinson (formerly VP of Developer Experience at Vercel, 2020–2025; now
75	VP of Developer Education at Cursor).** DX as community + education + docs;
76	templates and learning content as the top of the funnel.
77	- Wes Bush (ProductLed) / Elena Verna (Reforge). PQL signals and the
78	product-led + sales-assist hybrid that routes self-serve usage into sales at
79	the right moment (cross-reference `plg-strategy`).
80
81	## Prerequisites
82
83	- A product a developer can try without talking to sales (free tier, trial, or
84	open-source core) and a time-to-first-value you can measure.
85	- Public, ungated documentation and at least one working quickstart.
86	- Ability to instrument product/usage signals (signups, activation, usage near
87	plan limits) — see `plg-strategy` PQL scoring.
88	- Clarity on who the economic buyer is vs. who the developer/champion is.
89
90	## Step-by-Step Process
91
92	### Phase 1: Establish Developer Trust (Show, Don't Tell)
93
94	1. Ungate the funnel: docs, quickstarts, API reference, and SDKs are public and
95	indexed (DuVander; docs are the discovery and evaluation channel).
96	2. Publish transparent, self-serve pricing. Hiding price behind "contact sales"
97	is read as a red flag by technical buyers.
98	3. Make time-to-first-value minutes, not days: copy-paste quickstart, API keys
99	on signup (Stripe pattern), starter templates, zero-config defaults (Vercel).
100	4. Remove "lead" friction: no required demo, no gating real docs behind email.
101
102	### Phase 2: Build the Flywheel (Open Source / Framework Wedge)
103
104	1. Identify the free, credible artifact that creates pull: an open-source
105	framework/library, CLI, or SDK that is genuinely useful even un-monetized
106	(Next.js → Vercel). Keep it open and self-hostable.
107	2. Make the commercial product the natural extension of that artifact (hosting,
108	scale, collaboration, compliance), not a paywall on the core.
109	3. Feed the flywheel with credible content: templates/starters, benchmarks,
110	changelogs, and tutorials — assets developers reuse and share.
111
112	### Phase 3: Self-Serve → PQL → Sales-Assist
113
114	1. Let developers adopt bottom-up and reach value alone (Hobby/Pro self-serve).
115	2. Score PQLs on real usage: nearing plan limits, multiple seats on one account,
116	adoption spreading to a new team, "can we do X at scale / SSO / SOC2?"
117	questions (see `plg-strategy`, `freemium-optimization`).
118	3. Trigger sales only on qualified intent — and route to a technical seller
119	(Vercel's "Product Advocate" / technical AE), not a generic SDR blast.
120	4. Sell to the economic buyer (VP Eng/CTO/procurement) while enabling the
121	developer champion to make the internal case. Bottom-up adoption + top-down
122	commercial motion, timed off product signals — not the calendar.
123
124	### Phase 4: DevRel & Community as Distribution
125
126	1. Staff DevRel for developer success and credibility (quick wins, docs,
127	sample apps, conference talks), not as a lead-gen quota.
128	2. Run community where developers already are (GitHub, Discord, X, events like
129	ship/launch conferences) and contribute before extracting.
130	3. Measure DevRel by adoption, activation, and influenced pipeline — not raw
131	GitHub stars or follower counts.
132
133	## Output Format
134
135	A developer GTM plan containing: trust audit (ungated docs, transparent pricing,
136	time-to-first-value), the open-source/flywheel wedge (free artifact →
137	commercial extension), a self-serve → PQL → sales-assist motion with named
138	trigger signals and seller roles, a DevRel/community distribution plan with
139	non-vanity metrics, a developer-credible content list (templates, benchmarks,
140	changelogs, tutorials), and a champion-enablement plan separating the developer
141	from the economic buyer.
142
143	## Quality Check
144
145	- [ ] Docs, quickstart, and pricing are public and ungated (no demo wall)
146	- [ ] Time-to-first-value is measured and is minutes, not days
147	- [ ] There is a free, credible artifact (OSS/CLI/SDK) creating real pull
148	- [ ] Commercial product extends the free core; it does not paywall it
149	- [ ] PQL triggers are based on usage signals, not lead forms
150	- [ ] Sales engages only on qualified intent, via a technical seller
151	- [ ] Developer (champion) and economic buyer are addressed separately
152	- [ ] DevRel metrics are adoption/activation/pipeline, not vanity stars
153	- [ ] Every recommendation cites a named source, not "best practices"
154
155	## Common Pitfalls
156
157	1. Gating docs and pricing. Forcing email or "contact sales" to read docs
158	or see price kills evaluation. Developers self-serve or leave (DuVander).
159	2. Cold-calling/emailing developers. Spraying SDR sequences at the
160	technical user breaks trust. Use product signals to reach the buyer
161	thoughtfully; let the developer come to you (Stripe/Common Room).
162	3. Paywalling the open-source core. Restricting the free artifact to force
163	conversion breaks the flywheel. Monetize the extension (hosting, scale,
164	compliance), keep the core free (Next.js → Vercel).
165	4. Vanity GitHub stars. Stars and followers are not adoption. Measure
166	activation, retained usage, and influenced pipeline.
167	5. Treating DevRel as lead gen. A DevRel team on an SDR quota loses
168	credibility with developers. DevRel earns trust; sales closes.
169	6. Confusing the user with the buyer. The developer recommends; the
170	economic buyer signs. Enable the champion, sell the buyer (Verna/Bush hybrid).
171
172	## Execution Artifacts
173
174	- `references/framework-notes.md` — Framework index and authority routing
175	- `templates/output-template.md` — Deliverable shell for the developer GTM plan
176	- `scripts/check-output.py` — Lightweight deliverable validator
177	- `references/vercel-developer-selling.md` — Vercel case deep-dive, sourced specifics, agent-routing table
178
179	## Related Skills
180
181	- plg-strategy: Self-serve model selection, PQL scoring, product-led + sales hybrid
182	- freemium-optimization: Free tier design and free-to-paid conversion
183	- founder-brand: Founder-led credibility and developer community presence
184	- content-led-growth: Docs, tutorials, and content as the developer funnel
185

Files of Developer GTM (Selling to Developers)

Developer GTM (Selling to Developers)

Overview

When to Use

Authoritative Foundations

Prerequisites

Step-by-Step Process

Phase 1: Establish Developer Trust (Show, Don't Tell)

Phase 2: Build the Flywheel (Open Source / Framework Wedge)

Phase 3: Self-Serve → PQL → Sales-Assist

Phase 4: DevRel & Community as Distribution

Output Format

Quality Check

Common Pitfalls

Execution Artifacts

Related Skills

Discussion

Alternatives