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.
Build and scale developer-led adoption through ecosystem programs, community, and partnerships. Focus on what actually drives adoption, not vanity metrics.
When to Use
Triggers:
"How do we build a developer ecosystem?"
"Should we curate quality or go open?"
"Developer community isn't growing"
"Nobody's building on our API"
"How do we compete with larger platforms?"
Context:
API platforms and developer tools
Products with extensibility (plugins, integrations)
Developer-first GTM motion
Platform business models
Core Frameworks
1. Open vs Curated Ecosystem (The Marketplace Decision)
The Pattern:
Running ecosystem at a developer platform. Leadership debate: Open the marketplace to anyone, or curate for quality?
Related Skills
Quality control camp: "We need gatekeeping. Otherwise we'll get SEO spam, low-quality integrations, brand damage."
Open camp: "Developers route around gatekeepers. Network effects matter more than quality control."
The decision: Went open. Quality concerns were real, but we made a bet: control comes from discovery and trust layers, not submission gatekeeping.
What We Built Instead of Gatekeeping:
Search and discovery — Surface high-quality integrations through algorithms, not human curation
Trust signals — Verified badges, usage stats, health scores
Community curation — User ratings, collections, recommendations
Moderation — Remove spam after publication, not block before
Result: Network effects won. Thousands of integrations published. Quality surfaced through usage, not through us deciding upfront.
Decision Framework:
Curated works when: Brand risk high, dozens of partners, can scale human review
Open works when: Hundreds/thousands of potential partners, network effects matter more than quality control
Common Mistake:
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.
2. The Three-Year Student Program Arc
The Pattern:
Most developer programs optimize for quick wins. Better approach: Build long-term talent pipeline.
Year 1: University Partnerships
Partner with CS departments
Curriculum integration (hackathons, coursework)
Student licenses (free or heavily discounted)
Metrics: # universities, # students activated
Year 2: Student Community & Certification
Student expert certification program
Student-led workshops and events
Campus ambassadors
Metrics: # certified, # student-led events
Year 3: Career Bridge
Job board connecting students → companies
Enterprise partnerships (hire certified students)
Alumni network
Metrics: # hired, company partnerships
Why This Works:
Students become enterprise buyers 5-10 years later. You're building brand loyalty before they have purchasing power.
Common Mistake:
Treating students as immediate revenue. They're not. They're future enterprise decision-makers.
Measuring vanity metrics (sign-ups, downloads) instead of real engagement (API calls, production deployments).
4. Documentation Hierarchy
Tier 1: Quick Starts (Get to Value Fast)
"Hello World" in 5 minutes
Common use case examples
Copy-paste code that works
Tier 2: Guides (Solve Real Problems)
Use case-specific tutorials
Integration patterns
Best practices
Tier 3: Reference (Complete API Docs)
Every endpoint documented
Request/response examples
Error codes and handling
Tier 4: Conceptual (Understand the System)
Architecture overviews
Design philosophy
Advanced patterns
Most developers need: Tier 1 first, then Tier 2. Very few read Tier 4.
Common Mistake:
Starting with Tier 3 (comprehensive API reference). Developers want quick wins first.
5. Community vs Support (When to Use Which)
Community (Async, Scalable):
Slack/Discord for real-time help
Forum for searchable Q&A
GitHub discussions for feature requests
Best for: Common questions, peer-to-peer help
Support (Sync, Expensive):
Email support for enterprise
Dedicated Slack channels for partners
Video calls for complex integrations
Best for: Paying customers, strategic partners
How to Route:
Community first:
Developer asks question
Community member answers
You validate and upvote
Searchable for future developers
Escalate to support when:
No community answer in 24 hours
Enterprise/paying customer
Security or compliance issue
Complex integration requiring custom work
Common Mistake:
Providing white-glove support to everyone. Doesn't scale. Build community that helps itself.
6. Partner Tiering for Developer Ecosystems
Tier 1: Integration Partners (Self-Serve)
Build with public API
You provide: docs, Slack channel, office hours
They drive their own marketing
Best for: Ambitious partners with resources
Tier 2: Strategic Partners (Co-Development)
Co-developed integration
You provide: dedicated channel, co-marketing
Joint case studies
Best for: High-impact integrations
Don't over-tier. 2 tiers is enough. More creates confusion.
Decision Trees
Open or Curated Ecosystem?
Is brand damage risk high if low-quality partners join?
├─ Yes (regulated, security) → Curated
└─ No → Continue...
│
Can you scale human review?
├─ No (hundreds/thousands) → Open + discovery systems
└─ Yes (dozens) → Curated
Community or Support?
Is this a common question?
├─ Yes → Community (forum, Slack, docs)
└─ No → Continue...
│
Is requester paying customer?
├─ Yes → Support (email, dedicated)
└─ No → Community (with escalation path)
Common Mistakes
1. Building ecosystem before product-market fit
Fix core product first, then build ecosystem
2. No developer success team
Developers need help to succeed beyond docs
3. Poor documentation
Foundation of ecosystem, non-negotiable
4. Treating all developers equally
Tier support by strategic value (paying > free, partners > hobbyists)
5. No integration quality standards
Low-quality integrations hurt your brand
6. Measuring only vanity metrics
Track activation and production usage, not just sign-ups
7. Developer advocates with no technical depth
Hire developers who can code and teach
Quick Reference
Open ecosystem checklist:
Search and discovery (surface quality algorithmically)
Community curation (user recommendations, collections)
Moderation (remove spam after publication)
Developer journey metrics:
Awareness: Traffic, sign-ups
Onboarding: Time to first API call (<10 min target)
Integration: % reaching production deployment
Advocacy: Developer NPS, public sharing
Documentation hierarchy:
Quick starts (5-min "Hello World")
Use case guides (solve real problems)
API reference (complete documentation)
Conceptual (architecture, philosophy)
Partner tiers:
Tier 1: Self-serve (public API, docs, community)
Tier 2: Strategic (co-development, co-marketing)
Student program timeline:
Year 1: University partnerships, activation
Year 2: Certification, student community
Year 3: Job board, enterprise hiring bridge
Related Skills
partnership-architecture: Partner deal structures and co-marketing
product-led-growth: Self-serve activation funnels for developer products
0-to-1-launch: Launching developer products
Based on building developer ecosystems at multiple platform companies, including the open vs curated marketplace decision, student program development (3-year arc building talent pipeline), and partner ecosystem growth. Not theory — patterns from building developer ecosystems that actually drove platform adoption and multi-year brand loyalty.