Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchAI, startups & growth insights. No spam.
TL;DR: Developer ecosystems are the highest-leverage distribution channel available to B2B startups today. Stripe grew to a $95B valuation not because their payment infrastructure was technically superior, but because 4 million developers chose to build on it. Twilio didn't win on SMS pricing — they won by making every developer feel like a hero. This is the API-first growth playbook: how to design developer experience as a growth lever, build an integration ecosystem that compounds, price APIs to incentivize adoption, and use MCP as the new API surface for AI-native products. If your product has any programmable layer, this is the most important article you'll read this quarter.
Most founders think of their API as a technical feature. A way to let enterprise customers integrate. A checkbox on the sales slide deck. Something the engineering team owns and the growth team ignores.
This framing is the single most expensive mistake you can make if your product has any programmable surface.
API-first growth is a distribution strategy, not an engineering decision. It means treating your API as your primary go-to-market channel — designing it to be discovered, adopted, loved, and talked about by the developers who will embed it into their products, recommend it to their teams, and evangelize it at conferences for the next decade.
The distinction matters because the growth mechanics are completely different.
When you think of your API as a technical feature, you optimize for completeness: every endpoint documented, every edge case handled, every SDK updated. When you think of your API as a growth channel, you optimize for something harder to measure but far more valuable: the first 15 minutes of a developer's experience. The time from "I found this" to "I have something working." That window determines whether you get a champion inside a company or a bounce back to your competitor.
The distribution moat for API-first companies comes from a compounding effect that traditional SaaS growth doesn't replicate. Every developer who integrates your API is:
The Postman 2023 State of the API Report found that 68% of developers discover APIs through word of mouth from colleagues. Not ads. Not SEO. Not sales outreach. Developers trust other developers, and API-first growth is fundamentally a strategy for becoming the product that developers trust enough to recommend.
Let's talk about the two companies who built this into a religion.
In 2011, if you wanted to accept payments online, you negotiated with a bank. You filled out PDFs. You waited weeks for merchant account approval. You integrated with documentation that read like it was written by a compliance lawyer for a compliance lawyer.
Patrick and John Collison built Stripe on a single insight: developers are the buyers, not just the implementers. The decision of which payment processor to use was being made by engineers who had autonomy over technical choices, not by finance departments who would have compared fees in a spreadsheet. If you win the engineer, you win the company.
Their legendary seven-line integration was not a marketing stunt. It was a direct attack on the cognitive cost of switching. They calculated that every additional line of code required to integrate was friction that translated into lost adoption. So they designed the API from the developer's perspective first, the business logic second, and the internal architecture third. In the API economy, developer ergonomics is competitive strategy.
Stripe then built infrastructure around keeping developers inside their ecosystem:
Stripe's current ecosystem includes over 4 million developers and processes hundreds of billions in payments annually. The product quality is excellent. But the real moat is the ecosystem gravity.
Twilio executed the same playbook in communications. Jeff Lawson's founding principle was that every software company should be able to access the communications layer the same way they access compute from AWS. Developer empowerment as product positioning.
Twilio's growth hack was the demo. At conferences, Twilio reps would live-code a working SMS notification in under five minutes, on stage, in front of developers who had spent weeks integrating competitors' SDKs. The demo was the product. It was designed to make every developer in the audience think "I could do that." That thought is the most powerful conversion trigger in developer marketing.
The pattern across both companies reveals the core API-first growth formula:
DX — developer experience — is the API-first equivalent of UX for consumer products. Except the consequences of bad DX are more severe. A consumer frustrated by a bad UI might rant on Twitter. A developer frustrated by a bad API will integrate a competitor and then actively warn their network away from you.
The components of DX that drive adoption are:
The majority of developers abandon a new API at the documentation stage. Not because the API is bad — but because they cannot figure out how to make it do the thing they need to do within the first few minutes.
Effective API documentation has three layers:
Quickstart — a completely contained example that produces visible output in under 5 minutes. Not "here are all our concepts explained." A working thing. A webhook that logs to console. A payment that charges a test card. A message that sends to a phone number. The quickstart should feel like magic because it should work the first time, without any configuration decisions.
Reference — exhaustive, machine-readable documentation of every endpoint, parameter, response shape, and error code. This is table stakes. Use ReadMe or similar tooling to keep reference documentation synchronized with your actual API behavior. Nothing destroys developer trust faster than documentation that doesn't match what the API actually does.
Guides — use-case-oriented tutorials that bridge the quickstart and the reference. "How to build a subscription billing system." "How to handle webhook retries." "How to test in sandbox before production." Guides are where developers learn your mental model, not just your syntax.
Every language your target developers use should have an officially maintained SDK. This is not optional for serious API-first companies — it is table stakes.
But there is a quality dimension that separates good SDKs from great ones. Great SDKs:
sk_ prefix" not "Authentication failed")Stripe's SDKs are open-source and accept community contributions. This is both a quality signal and a growth strategy — contributors become evangelists.
Production-like sandboxes are a conversion accelerator. Developers who can test against real-world conditions — retry logic, webhook delivery, error scenarios, rate limiting — ship to production faster and with more confidence. They also trust your product more, because they have already debugged against it.
The sandbox design should mirror production exactly. Separate API keys, full documentation coverage, realistic test fixtures (test credit card numbers, test phone numbers, test webhook payloads). Twilio's sandbox environment was so good that developers built their entire test suites against it, creating a dependency that made switching to a competitor a non-trivial engineering project.
Static documentation has one major limitation: it requires developers to set up their own environment before they can validate that an API call works. Interactive explorers — inline code runners, Postman collections, API playground tools — remove this friction entirely.
The developer who makes their first successful API call inside your documentation page has a meaningfully higher conversion rate to paid than the developer who has to set up their local environment first. Measure this. The data will convince your engineering team to prioritize the investment.
The developer adoption funnel is different from a traditional B2B sales funnel in ways that matter for how you allocate resources.
Awareness — developers discover APIs through: technical blog posts ranking in Google, conference talks and demos, recommendations from colleagues, open-source repositories that list dependencies, integrations in tools they already use, and increasingly, AI coding assistants that suggest libraries and SDKs.
Evaluation — this is where most traditional companies focus: the marketing site, the pricing page, the feature comparison. But developers actually evaluate by trying. The documentation quality, the quickstart experience, and whether the sandbox works without friction are the real evaluation signals. A developer who cannot get a working example in 15 minutes will not read your feature comparison.
Activation — the moment a developer successfully integrates your API into their own codebase, even in a test environment. This is your most important leading indicator. Track time-to-activation by cohort, by acquisition source, by programming language. Developers who activate within 24 hours of signup have dramatically higher 90-day retention than those who take a week.
Integration Depth — not all integrations are equal. A developer who uses one endpoint for a side project is not the same as a developer who has integrated five endpoints into their company's production systems. Integration depth is your switching cost. As developers go deeper, the cost of migrating to a competitor grows non-linearly.
Advocacy — the top of the funnel for your next developer. Advocates write blog posts, answer Stack Overflow questions, give conference talks, recommend you in Slack communities, and include you in their personal projects. Advocacy is the output of exceptional DX compounded over time. You cannot buy it, but you can create the conditions for it.
The metric that ties this funnel together is Developer NPS — not traditional NPS, but specifically asking developers: "How likely are you to recommend this API to a colleague?" Track it separately from business NPS. The scores will diverge. Developer NPS is the leading indicator of ecosystem growth.
Developer Relations (DevRel) and developer marketing are often conflated and occasionally at war with each other inside companies. Understanding the distinction is critical for building an API-first growth function that actually works.
Developer marketing is outbound. It is advertising to developers, creating content that brings developers to your product, running campaigns that drive sign-ups. It is measured in MQLs, conversion rates, and cost per acquisition. Developer marketing is a valid investment, but it operates on developer attention — a resource that is finite and increasingly hostile to traditional marketing approaches.
DevRel is trust arbitrage. DevRel professionals build relationships with developer communities — not as brand ambassadors, but as members of those communities who happen to work at a company. The best DevRel programs operate on the premise that value given to the community (conference talks, open-source contributions, technical tutorials, honest API feedback sessions) builds trust that converts at dramatically higher rates than any paid campaign.
The structural difference: developer marketing scales with budget. DevRel scales with trust, and trust is earned slowly and destroyed instantly.
For an API-first company in its first three years, the resource allocation question is: hire DevRel before you hire developer marketing. A great DevRel hire — someone who is a respected member of the communities your target developers belong to — can generate more qualified developer sign-ups in their first year than an equivalent spend on paid developer advertising. They can also surface DX issues faster than any user research process.
The DevRel function should own:
Developer marketing should own:
The collaboration point is technical content. DevRel writes it, developer marketing distributes and optimizes it. This is where the two functions produce compounding returns when they work well together.
The integration marketplace is the highest-leverage long-term investment in API-first growth, and the most underinvested function in most API-first companies.
Here is the core mechanic: every integration you have with a platform your developers already use is a distribution channel. When your API shows up as an option inside Zapier, inside Make, inside the Salesforce AppExchange, inside the Shopify App Store — developers and technical operators who were never going to find you through SEO or conference talks discover you in the context of a problem they are actively trying to solve.
The network effect compounds: the more integrations you have, the more valuable your API becomes (because it connects to more of a developer's existing stack), which attracts more developers, which attracts more integration partners, which creates more integrations.
This is the distribution moat that is hardest to replicate because it is not a product feature — it is a set of relationships and technical investments that compound over years.
Not all integrations are equal in their growth impact. Structure your integration strategy around three tiers:
Tier 1 — Platform Integrations: The high-leverage partnerships with platforms your target developers already live inside. For a developer-first product, this means GitHub (Actions, Apps Marketplace), VS Code extensions, Slack apps, and CLI tools that integrate with existing workflows. These integrations have the highest developer discovery surface because they are shown to developers who are already in their working context.
Tier 2 — Ecosystem Integrations: Integrations with complementary API-first products that serve overlapping developer audiences. If you are building an authentication API, integrating with the major backend frameworks (Next.js, Django, Rails, Laravel) is a Tier 2 integration — it is not a platform partnership but it dramatically reduces the time to integration for developers using those frameworks. These integrations also create co-marketing opportunities: both companies can reference each other in their documentation.
Tier 3 — Community Integrations: Integrations built by your users, not your team. These are the SDKs for niche languages your engineering team will never prioritize, the plugins for obscure but dedicated communities, the tools that solve edge cases you did not anticipate. Community integrations are a signal of ecosystem health — they only appear when your developer community is large and engaged enough to build for each other.
Building a partner integration is a business development exercise, not just an engineering project. The steps:
Identify integration targets by developer overlap — use data from your existing user base to find which tools your developers are already using. If 40% of your developers are also GitHub users who use GitHub Actions, a GitHub Actions integration is a Tier 1 priority.
Build a reference integration first — before approaching a partner, build the integration yourself so you understand the technical requirements and can demonstrate value. Partners are far more receptive to "we built this integration and our users are asking for it" than "we think an integration would be mutually beneficial."
Seek listings in partner marketplaces — every major platform has a marketplace (Shopify App Store, Atlassian Marketplace, Salesforce AppExchange, Zapier App Directory). Getting listed is a distribution unlock that compounds without additional investment.
Create co-marketing content — joint blog posts, joint webinars, joint tutorial videos. Each piece of co-marketing content appears in both companies' distribution channels, doubling the reach.
Build a partner program with economic incentives — revenue share, referral fees, or free API credits for integration partners who drive significant qualified traffic. Economic incentives align partner behavior with your growth goals.
The pricing model for an API-first product is a growth decision, not just a revenue decision. Pricing determines who can start using your API, how fast they can grow with it, and whether the economic model aligns your interests with your developers' success.
The core tension in API-first pricing: generous enough to enable adoption, structured enough to convert growing usage into revenue.
Usage-based pricing — charging per API call, per unit of compute, per message, per transaction — is the canonical model for API-first businesses because it eliminates the single biggest adoption barrier: upfront commitment.
A developer who has to get purchase order approval before testing your API will not test your API. Usage-based pricing with a free tier or a generous trial means a developer can go from discovery to production in the same afternoon, without talking to a salesperson or submitting a procurement request.
The growth mechanic: your revenue scales directly with your customers' success. When a startup you signed up for free grows to a Series B company processing thousands of API calls per hour, your revenue grows proportionally. You are structurally incentivized to help your customers succeed.
Stripe charges 2.9% + 30 cents per transaction. Every dollar your business processes is revenue for Stripe. The alignment is perfect.
The freemium model for APIs works differently from SaaS freemium. The conversion trigger is not a feature gate — it is a usage threshold. When a developer's usage grows to a point where they need production-grade reliability, compliance features, or SLAs that matter for a business, they convert to paid.
Design your free tier to be genuinely useful for:
The rate limit on your free tier is a product decision with direct growth implications. Too restrictive, and developers cannot build anything meaningful and move on. Too generous, and you fund production usage without revenue. The right threshold is: the free tier should be enough to build a complete prototype and validate the integration, but not enough to run a production business.
The enterprise pricing tier creates a potential conflict in API-first companies: you need high-ASP enterprise contracts to fund growth, but enterprise procurement processes are the natural enemy of developer-led adoption.
The solution is to separate the developer adoption path from the enterprise commercial path. Let developers self-serve all the way to significant usage. Build a clear off-ramp where large enterprise accounts are introduced to a commercial conversation based on their usage data, not a sales-initiated outreach.
Twilio mastered this: developers could self-serve to $10,000/month in spend, then an account executive reached out with volume discounts and an enterprise SLA — at the exact moment when the integration was already production-critical, making the conversation about reducing costs rather than justifying the investment.
Open source is not a product strategy. It is a distribution strategy. The distinction is important because it reframes how you think about the cost/benefit of open-sourcing components of your API stack.
When you open-source a component of your product — an SDK, a developer tool, a reference implementation — you are making a calculated investment: you are giving away something valuable in exchange for distribution, trust, and community. The calculation works when:
The open-source moat is community, not code. Your competitors can fork your code. They cannot fork your contributors, your community norms, your documentation culture, or the network of integrations built on top of your open-source project.
HashiCorp built their entire go-to-market on open-source tooling (Terraform, Vault, Consul) that developers adopted individually and then brought into their organizations. Elastic built a search company on top of an open-source search engine. Confluent built a streaming data company on top of open-source Kafka. In each case, the open-source project was the top-of-funnel; the commercial product was the conversion event.
For an API-first startup, the practical open-source strategy is:
Open-source your SDKs — immediately. This enables community contributions that extend your language coverage, surfaces bugs faster, and signals long-term commitment to your developer community.
Open-source your developer tools — CLI tools, local development environments, testing utilities. These tools make developers more productive, which increases adoption, which drives API usage, which is your actual revenue line.
Open-source reference implementations — example applications that demonstrate best practices for integrating your API. Developers who learn from your reference implementation are more likely to integrate correctly, have better retention, and recommend you to peers.
Keep your core API infrastructure closed — the distributed systems, the reliability engineering, the security hardening. This is where you compete on quality, and open-sourcing it would eliminate the technical differentiation that justifies your pricing.
The emergence of the Model Context Protocol (MCP) represents the most significant expansion of API-first distribution since the smartphone created mobile SDKs as a new distribution surface.
MCP — developed by Anthropic and increasingly adopted across the AI tooling ecosystem — is a standardized protocol that allows AI models to connect to external tools, data sources, and APIs in a structured, discoverable way. If you are not familiar with the technical details, I wrote a deep-dive on MCP integration for SaaS products.
The growth implication is significant: an MCP server for your product is a new API surface that places your functionality inside every AI coding assistant, every AI agent framework, and every AI-native workflow tool that supports MCP.
When a developer is using Claude, Cursor, or another MCP-enabled AI assistant to build something, they can invoke your API functionality through the AI's tool-calling mechanism — without leaving their development environment, without switching context, and often without explicitly searching for your product. Your functionality becomes part of the AI's capability set.
This is AI-native product design applied to distribution: instead of waiting for developers to discover and integrate your API, you make your API discoverable by the AI tools that developers are already using constantly.
The MCP ecosystem is early — which means the compounding advantage of being an early, high-quality MCP implementation is significant. The developer who discovers your product through an MCP tool invocation in Claude or Cursor has a discovery experience that is qualitatively different from reading your marketing site. They see your product solving a real problem in their actual workflow, at the exact moment they need it.
Think of MCP servers as the new integration marketplace: the developers who build the most useful, reliable MCP servers for their products will capture disproportionate discovery and adoption from the rapidly growing AI-native developer segment.
The technical requirements for an MCP server are significantly lower than building a full REST API — the protocol handles authentication, tool discovery, and structured I/O. An engineer can build a functional MCP server for a product that already has a REST API in a day or two. The growth return on that engineering investment, relative to its cost, is extremely high.
Step 1: Audit your existing API surface for which endpoints create the most value in an agentic context. Not everything translates — CRUD operations on internal data are less useful in an AI context than search, retrieval, creation, and action-triggering.
Step 2: Build an MCP server that exposes your highest-value agentic operations as tools. Each tool should have a natural language description that is discoverable by AI models — this is where copywriting and technical writing intersect in an interesting new way.
Step 3: List your MCP server in the growing ecosystem of MCP server registries. Submit to the official Anthropic MCP servers list, the community-maintained awesome-mcp-servers repositories, and any domain-specific registries that emerge.
Step 4: Build quickstart documentation for MCP specifically — "How to use [Product] in Claude" tutorials that rank for the growing search traffic around MCP integration queries.
Step 5: Treat your MCP server as a first-class API product with versioning, changelog, and uptime monitoring. Reliability is the most critical DX attribute for agentic workloads because failures are often silent and compound across multi-step agent pipelines.
The product defensibility dimension here is interesting: an MCP server with high quality, reliable tool implementations and rich documentation will accumulate usage patterns, developer trust, and ecosystem integrations that are difficult for a competitor to replicate quickly.
Pulling this together into a practical framework for a founder building an API-first company from scratch or retrofitting API-first growth onto an existing product.
Foundational (Build First)
Growth Infrastructure (Build in First 6 Months)
Ecosystem Layer (Build in First 18 Months)
Amplification Layer (Ongoing)
The API-first growth metrics that matter:
Do not conflate API calls with adoption. A developer could make 10,000 API calls testing your sandbox and never go to production. Measure intent-to-integrate signals: sandbox-to-production conversion rate, multi-endpoint usage, return visit frequency after the first session.
API-first growth requires a cross-functional team structure that most B2B SaaS companies are not organized for.
Developer Platform team — owns the API, SDKs, documentation, and sandbox. Engineers who have a designer sensibility. Their north star metric is TTFAC.
DevRel team — owns community, conferences, technical content, and champion programs. Reports to a growth function, not engineering. Measured on Developer NPS and community growth.
Developer Marketing team — owns SEO, paid acquisition, email nurture for developer audiences. Works closely with DevRel on content distribution.
Partner Engineering team — owns the integration marketplace, partner technical integrations, and MCP server. This function is often underinvested and is where significant distribution leverage sits.
The mistake most companies make: they staff Developer Platform and DevRel but skip Partner Engineering, leaving the integration marketplace as a "someday" project while their competitors build the distribution network they never will.
What is the difference between an API-first company and a company that has an API?
An API-first company treats the API as the primary product — the thing that is designed first and optimized for developer experience. A company that has an API built it as an afterthought to enable integrations for existing customers. The distinction shows in documentation quality, SDK investment, sandbox environments, and whether the API has its own product roadmap or depends on the internal product team's priorities.
How much should a seed-stage startup invest in developer experience?
More than you think, less than you fear. At seed stage, the minimum viable DX investment is: one complete quickstart tutorial per major programming language your users write in, a sandbox environment that mirrors production, and API keys that work on signup without manual approval. The cost is primarily engineering time, not cash. The return is measured in activation rates and developer NPS — both of which compound into word-of-mouth growth that no seed-stage marketing budget can replicate.
When should we hire our first DevRel engineer?
When you have enough developers using your API that you have real community activity to engage with — typically around 500-1000 active developers. Hiring DevRel before you have an active community is like hiring a community manager for an empty room. The first DevRel hire should be someone who is already an active member of the communities your target developers belong to. Their existing trust network is the real asset.
How do we compete with the developer ecosystems of companies like Stripe and Twilio?
You do not compete head-on. You compete by owning a specific vertical or use case with more domain depth than a horizontal platform can provide. A payments API built specifically for marketplace businesses, or a communications API built specifically for healthcare, can out-execute Stripe and Twilio in their specific domain because the domain-specific documentation, compliance guidance, and integration examples are orders of magnitude more useful than the generic equivalents. Depth beats breadth for developer adoption in vertical markets.
Is open-sourcing our SDK worth the maintenance burden?
Yes, with the condition that you staff for it. An open-source SDK that is not maintained is worse than a closed-source SDK — it signals to developers that you do not care about your community, and old issues accumulate as public documentation of your product's failure modes. If you open-source an SDK, assign a specific engineer to review and merge contributions within 48 hours, triage issues weekly, and publish a changelog with every release. The maintenance burden is real but the community return — bug reports, language coverage, advocacy — is substantial.
What is the fastest way to build our integration marketplace from zero?
Zapier first. The technical investment to build a Zapier integration is low (a few days of engineering time), and the distribution return is immediate — you get listed in Zapier's app directory, which surfaces you to hundreds of thousands of operators who use Zapier as their automation layer. The second integration should be Make (formerly Integromat) for the same reason. These two integrations expand your total addressable user base from "developers who write code" to "technical operators who use no-code automation tools." The resulting usage data often reveals use cases you did not anticipate, which informs your native integration roadmap.
How does MCP change the API-first growth playbook?
MCP is additive, not replacement. Your REST API, SDKs, and documentation remain the foundation. MCP adds a new discovery surface: instead of developers finding your API through Google, GitHub, or conference talks, they encounter your functionality through AI tools they are already using. The practical impact is highest for products whose value proposition is best demonstrated in context — when an AI coding assistant can invoke your API to solve a problem the developer is actively working on, the conversion from discovery to adoption is dramatically faster than any marketing-initiated touchpoint. Build MCP support alongside your REST API, not instead of it.
What is the right pricing strategy for a developer tool that is used by both individual developers and enterprise teams?
Two separate pricing tracks with a clear transition mechanism. Individual developers should be able to use your API with a credit card and no sales conversation, at a price point where a developer can validate the integration for a personal project without a significant financial commitment. Enterprise teams need volume pricing, SLAs, compliance documentation, and often a legal contract — none of which a self-serve system can provide. The transition mechanism: automated outreach when a developer's usage crosses a threshold that indicates production use at scale (say, $500/month in API spend), with an offer to move to a volume pricing tier with additional enterprise features. Do not gate production use behind a sales conversation — you will lose every developer who is not given purchase approval authority.
How important is developer documentation SEO versus other channels?
Extremely important, and systematically underinvested in most API-first companies. Developer documentation has unique SEO properties: long-tail technical queries have high intent, low competition (most competitors do not optimize documentation for search), and high retention once you rank (developers bookmark documentation pages and return repeatedly). A well-optimized documentation SEO strategy — targeting "how to [integrate task] with [programming language]" query patterns — can generate qualified developer sign-ups at a cost-per-acquisition that paid developer acquisition cannot approach. The investment: a technical writer with SEO knowledge, or a dedicated SEO resource who can work with your technical team on query research and content structure.
Building an API-first growth strategy? The ecosystem compounds faster than you expect — and slower than you want. The companies that win are the ones who treat developer experience as their primary competitive battleground and start investing before they feel the urgency to.
If you are thinking about distribution strategy more broadly, read Distribution Is the Only Moat Left — the API ecosystem is one of five distribution moats that still hold in the AI era.
Cold outbound reply rates are below 1%. Nearbound — selling through warm partner ecosystem paths — is the B2B growth motion replacing it. Here's the complete playbook.
How reverse trials — giving users full product access before downgrading — convert 2-3x better than freemium. The complete playbook with case studies from Ahrefs, Loom, and Calendly.
Enterprise buyers want to try before they talk to sales. Here's how Notion, Figma, and Vercel built self-serve pipelines to six-figure contracts — and how your startup can too.