developer-ecosystem

Name: developer-ecosystem
Author: beingsmit

39stars7forks

How to install developer-ecosystem?

beingsmit/technical-product-gtm/developer-ecosystem

$npx -y skills add beingsmit/technical-product-gtm --skill developer-ecosystem

Installs into the current project.

Summary

Build and scale developer-led adoption through ecosystem programs. Use when deciding open vs curated ecosystems, building developer programs, scaling platform adoption, or designing student program pipelines.

Files · 1

View on GitHub

SKILL.md

1	# Developer Ecosystem
2
3	Build and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.
4
5	## When to Use
6
7	Triggers:
8	- "How do we build a developer ecosystem?"
9	- "Should we curate quality or go open?"
10	- "Developer community isn't growing"
11	- "Nobody's building on our API"
12	- "How do we compete with larger platforms?"
13
14	Context:
15	- API platforms and developer tools
16	- Products with extensibility (plugins, integrations)
17	- Developer-first GTM motion
18	- Platform business models
19
20	---
21
22	## Core Frameworks
23
24	### 1. Open vs Curated Ecosystem (The Marketplace Decision)
25
26	The Pattern:
27
28	Running ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?
29
30	Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage."
31
32	Open camp: "Developers route around gatekeepers. Network effects matter more than quality control."
33
34	The decision: Went open. Quality concerns were real, but we made a bet: control comes from discovery and trust layers, not submission gatekeeping.
35
36	What We Built Instead of Gatekeeping:
37
38	1. Search and discovery — Surface high-quality integrations through algorithms, not human curation
39	2. Trust signals — Verified badges, usage stats, health scores
40	3. Community curation — User ratings, collections, recommendations
41	4. Moderation — Remove spam after publication, not block before
42
43	Result: Network effects won. Thousands of integrations published. Quality surfaced through usage, not through us deciding upfront.
44
45	Decision Framework:
46	- Curated works when: Brand risk high, dozens of partners, can scale human review
47	- Open works when: Hundreds/thousands of potential partners, network effects matter more than quality control
48
49	Common Mistake:
50
51	Defaulting to curated because "we need quality control." This works when you have 10 partners. At 100+, you become the bottleneck. Build discovery and trust systems instead.
52
53	---
54
55	### 2. The Three-Year Student Program Arc
56
57	The Pattern:
58
59	Most developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.
60
61	Year 1: University Partnerships
62	- Partner with CS departments
63	- Curriculum integration (hackathons, coursework)
64	- Student licenses (free or heavily discounted)
65	- Metrics: # universities, # students activated
66
67	Year 2: Student Community & Certification
68	- Student expert certification program
69	- Student-led workshops and events
70	- Campus ambassadors
71	- Metrics: # certified, # student-led events
72
73	Year 3: Career Bridge
74	- Job board connecting students → companies
75	- Enterprise partnerships (hire certified students)
76	- Alumni network
77	- Metrics: # hired, company partnerships
78
79	Why This Works:
80
81	Students become enterprise buyers 5-10 years later. You're building brand loyalty before they have purchasing power.
82
83	Common Mistake:
84
85	Treating students as immediate revenue. They're not. They're future enterprise decision-makers.
86
87	---
88
89	### 3. Developer Journey (Awareness → Integration → Advocacy)
90
91	Stage 1: Awareness
92	- How do they discover you?
93	- Content, search, word-of-mouth, events
94
95	Stage 2: Onboarding
96	- First API call in <10 minutes
97	- Quick-start guides
98	- Sample code in popular languages
99
100	Stage 3: Integration
101	- Building real use cases
102	- Integration guides
103	- Support when stuck
104
105	Stage 4: Production
106	- Deployed and generating value
107	- Monitoring usage
108	- Enterprise upgrade path
109
110	Stage 5: Advocacy
111	- Sharing publicly
112	- Recommending to others
113	- Contributing back (docs, code, community)
114
115	Metrics That Matter:
116	- Time to first API call (onboarding)
117	- % reaching production (integration success)
118	- Monthly active developers (engagement)
119	- Developer NPS (advocacy)
120
121	Common Mistake:
122
123	Measuring vanity metrics (sign-ups, downloads) instead of real engagement (API calls, production deployments).
124
125	---
126
127	### 4. Documentation Hierarchy
128
129	Tier 1: Quick Starts (Get to Value Fast)
130	- "Hello World" in 5 minutes
131	- Common use case examples
132	- Copy-paste code that works
133
134	Tier 2: Guides (Solve Real Problems)
135	- Use case-specific tutorials
136	- Integration patterns
137	- Best practices
138
139	Tier 3: Reference (Complete API Docs)
140	- Every endpoint documented
141	- Request/response examples
142	- Error codes and handling
143
144	Tier 4: Conceptual (Understand the System)
145	- Architecture overviews
146	- Design philosophy
147	- Advanced patterns
148
149	Most developers need: Tier 1 first, then Tier 2. Very few read Tier 4.
150
151	Common Mistake:
152
153	Starting with Tier 3 (comprehensive A

People who liked this also viewed

6 picks

Type

developer-ecosystem

39stars7forks

View on GitHub

How to install developer-ecosystem?

beingsmit/technical-product-gtm/developer-ecosystem

$npx -y skills add beingsmit/technical-product-gtm --skill developer-ecosystem

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Developer Ecosystem
2
3	Build and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.
4
5	## When to Use
6
7	Triggers:
8	- "How do we build a developer ecosystem?"
9	- "Should we curate quality or go open?"
10	- "Developer community isn't growing"
11	- "Nobody's building on our API"
12	- "How do we compete with larger platforms?"
13
14	Context:
15	- API platforms and developer tools
16	- Products with extensibility (plugins, integrations)
17	- Developer-first GTM motion
18	- Platform business models
19
20	---
21
22	## Core Frameworks
23
24	### 1. Open vs Curated Ecosystem (The Marketplace Decision)
25
26	The Pattern:
27
28	Running ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?
29
30	Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage."
31
32	Open camp: "Developers route around gatekeepers. Network effects matter more than quality control."
33
34	The decision: Went open. Quality concerns were real, but we made a bet: control comes from discovery and trust layers, not submission gatekeeping.
35
36	What We Built Instead of Gatekeeping:
37
38	1. Search and discovery — Surface high-quality integrations through algorithms, not human curation
39	2. Trust signals — Verified badges, usage stats, health scores
40	3. Community curation — User ratings, collections, recommendations
41	4. Moderation — Remove spam after publication, not block before
42
43	Result: Network effects won. Thousands of integrations published. Quality surfaced through usage, not through us deciding upfront.
44
45	Decision Framework:
46	- Curated works when: Brand risk high, dozens of partners, can scale human review
47	- Open works when: Hundreds/thousands of potential partners, network effects matter more than quality control
48
49	Common Mistake:
50
51	Defaulting to curated because "we need quality control." This works when you have 10 partners. At 100+, you become the bottleneck. Build discovery and trust systems instead.
52
53	---
54
55	### 2. The Three-Year Student Program Arc
56
57	The Pattern:
58
59	Most developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.
60
61	Year 1: University Partnerships
62	- Partner with CS departments
63	- Curriculum integration (hackathons, coursework)
64	- Student licenses (free or heavily discounted)
65	- Metrics: # universities, # students activated
66
67	Year 2: Student Community & Certification
68	- Student expert certification program
69	- Student-led workshops and events
70	- Campus ambassadors
71	- Metrics: # certified, # student-led events
72
73	Year 3: Career Bridge
74	- Job board connecting students → companies
75	- Enterprise partnerships (hire certified students)
76	- Alumni network
77	- Metrics: # hired, company partnerships
78
79	Why This Works:
80
81	Students become enterprise buyers 5-10 years later. You're building brand loyalty before they have purchasing power.
82
83	Common Mistake:
84
85	Treating students as immediate revenue. They're not. They're future enterprise decision-makers.
86
87	---
88
89	### 3. Developer Journey (Awareness → Integration → Advocacy)
90
91	Stage 1: Awareness
92	- How do they discover you?
93	- Content, search, word-of-mouth, events
94
95	Stage 2: Onboarding
96	- First API call in <10 minutes
97	- Quick-start guides
98	- Sample code in popular languages
99
100	Stage 3: Integration
101	- Building real use cases
102	- Integration guides
103	- Support when stuck
104
105	Stage 4: Production
106	- Deployed and generating value
107	- Monitoring usage
108	- Enterprise upgrade path
109
110	Stage 5: Advocacy
111	- Sharing publicly
112	- Recommending to others
113	- Contributing back (docs, code, community)
114
115	Metrics That Matter:
116	- Time to first API call (onboarding)
117	- % reaching production (integration success)
118	- Monthly active developers (engagement)
119	- Developer NPS (advocacy)
120
121	Common Mistake:
122
123	Measuring vanity metrics (sign-ups, downloads) instead of real engagement (API calls, production deployments).
124
125	---
126
127	### 4. Documentation Hierarchy
128
129	Tier 1: Quick Starts (Get to Value Fast)
130	- "Hello World" in 5 minutes
131	- Common use case examples
132	- Copy-paste code that works
133
134	Tier 2: Guides (Solve Real Problems)
135	- Use case-specific tutorials
136	- Integration patterns
137	- Best practices
138
139	Tier 3: Reference (Complete API Docs)
140	- Every endpoint documented
141	- Request/response examples
142	- Error codes and handling
143
144	Tier 4: Conceptual (Understand the System)
145	- Architecture overviews
146	- Design philosophy
147	- Advanced patterns
148
149	Most developers need: Tier 1 first, then Tier 2. Very few read Tier 4.
150
151	Common Mistake:
152
153	Starting with Tier 3 (comprehensive A

People who liked this also viewed

6 picks

Type