How to Market to Developers (APIs, SDKs and AI Tools)

1. Blog
2. Demand & Channels

By Saroj Jha · October 4, 2026 · 16 min read

Developers adopt what they can try in minutes and trust what they can inspect. Make the first working call fast, keep the docs honest, and measure adoption, not impressions. The five steps below show how, with one example company from start to finish.

Most marketing advice assumes the buyer wants a conversation. A developer usually wants a result. If your product is an API, an SDK or an AI tool that engineers build with, the person who decides whether it lives or dies often never talks to you. They read your docs, run your example, and move on or stay.

The numbers point the same way. In the 2026 Stack Overflow Developer Survey, technical documentation was the most common answer to “How did you learn to code in the past year?” (58.9% of the 14,530 who answered), and AI coding tools came second, at 52.6%^[1]. For a founder that has a practical meaning: your docs are your first sales page, and more and more of the people reading them do so through an assistant.

This post answers the questions founders of developer-facing products ask me most often: who to market to first, how to get engineers to try the SDK instead of reading about it, whether you need a docs site and a GitHub presence, whether to hire developer relations or a growth marketer first, and what to say when a technical buyer says “we’ll build it ourselves.” It is orientation and AAJ’s judgement, not a guarantee of results.

Running case: Example Co. Fictional

The running case: Example Co. Example Co. is a fictional seed-stage AI developer tool: an API and a Python and TypeScript SDK that turn PDF documents into structured JSON using a language model. It has six people, including two founders (one is a former backend engineer who writes the docs) and no marketer yet. Its free tier covers 1,000 pages a month with no card, and paid use costs about $0.02 a page, so a typical paying team spends about $400 a month. About 2,000 people sign up each quarter, but only about 15% make a first successful call. The goal for the next two quarters is 300 weekly active developers and 25 paying teams. Example Co. and all its numbers are fictional and illustrative.

Step 1: Decide who you market to first

Founders often ask whether to market to developers or to business buyers. In a developer product there are usually two people, and they need different things at different times.

• The developer who tries. An engineer who wants to see whether the product solves a task. They need a key, a quickstart and a result.
• The person who approves. An engineering manager, head of product or security lead who decides whether the team keeps paying. They need proof of use, cost, and answers to risk questions.

My view is to start with the developer, because nobody approves a tool that nobody has used. Bring the approver in when real usage appears, and have the material ready (pricing, security answers, a usage summary) so a bottom-up sign-up does not stall at the first procurement question.

What Twilio’s filing shows

Twilio’s 2016 IPO filing is a clear primary-source example of a developer-first model. Under “Our Business Model for Innovators” it says: “Developers can begin building with a free trial,” and it calls the model “low friction.” It reported more than 900,000 registered developer accounts at March 31, 2016. The same filing is just as clear about the other side. In its risk factors it says that for enterprises “the decision to adopt our products may require the approval of multiple technical and business decision makers, including security, compliance, procurement, operations and IT,” and that it had “only recently established an enterprise-focused sales force”^[4]. These are what the filing says, not an account of how Twilio made its choices internally.

Example Co., step 1 Fictional

The founders list both audiences. The developer is a backend engineer at a company of 20 to 200 people who needs to turn invoices and contracts into JSON this week. The approver is the engineering manager who sees the bill. Example Co. decides that for the next two quarters the developer is the audience, with one action: make a first successful call. The approver gets one page, “For your team lead”, with pricing, a data-handling summary and a usage view. (Fictional.)

Do this

Write down your developer and your approver in one line each, and the single action you want each to take. If you cannot name the developer’s action, you are not ready to market to them.

Step 2: Get to the first working call in ten minutes

The question I hear most is how to get developers to try the SDK instead of just reading about it. My answer is to remove everything between “I’m curious” and “it worked on my data.”

The parts, in the order a developer meets them:

1. A key without a conversation. Sign-up with an email, a free tier with no card, and an API key shown on the first screen. That is the free-trial start Twilio’s filing describes^[4].
2. A quickstart that ends in a real result. One copy-paste example in the developer’s language that returns something useful, not “hello world.” For an extraction API, that means their own file in and clean JSON out.
3. A free tier big enough to finish a real task. If the free allowance runs out before a developer has judged quality on their own data, the free tier is a trial of your patience.
4. A fast, honest path when it fails. A readable error message, a status page and a place to ask. The first failure is the moment most people leave.

Ten minutes is a working target, not a proven threshold. I use it because it forces you to cut steps, and you should time your own quickstart rather than trust my number.

Example Co., step 2 Fictional

Today about 2,000 people sign up each quarter and only about 300 (15%) make a first successful call. The founders time the path with a new engineer: sign-up, email confirmation, a dashboard with five menus, a key hidden under Settings, a quickstart that needs a sample file from another page. It takes 31 minutes. They cut it to four steps: sign-up, key on the first screen, one command that runs on a bundled sample file, then “try your own file.” The new path takes 8 minutes. They then watch the share of sign-ups making a first call, not sign-ups. (All fictional.)

Do this

Ask someone who has never seen your product to go from sign-up to a first successful call while you watch without helping. Write down every place they pause.

Step 3: Treat the docs as your front door

If a developer decides after the quickstart, the docs decide whether they keep going. Founders ask me whether they need a docs site at all. For a developer product my answer is yes, before almost anything else, and it is the cheapest marketing asset you will build.

The evidence is consistent. Technical documentation topped Stack Overflow’s learning question in both 2025 and 2026 (Figure 3)^[1],[5]. On the supply side, Postman’s 2025 State of the API report, a vendor survey of more than 5,700 developers, architects and executives, found that 55% struggle with inconsistent documentation and 34% cannot find existing APIs within their own organization^[3]. If insiders struggle, outsiders struggle more. In my experience, a developer who hits wrong or missing docs rarely files a ticket. They try something else.

The docs set I would build first, in this order:

• Quickstart (Step 2), tested every release.
• API reference generated from your API spec, so it cannot drift from the product.
• Task guides that start from the job (“extract line items from an invoice”), each with code that runs.
• Limits, pricing and errors stated plainly: rate limits, what the free tier covers, what each error means. Hiding limits costs you trust the first time someone hits one.
• Changelog with dates, so developers can see the product is alive and what changed.

# Key: on the first screen after sign-up
from exampleco import Client, samples

client = Client(api_key="YOUR_API_KEY")
result = client.extract(samples.INVOICE)
print(result.json())

{
  "vendor": "Acme Supply Co.",
  "invoice_number": "INV-1042",
  "line_items": 12,
  "total": 418.2
}

One more reason to keep the docs clean: more of your readers now meet them through an assistant. In JetBrains’ 2026 Developer Ecosystem Survey, 90% of professional developers used AI coding agents at work at least weekly^[2], yet Postman found that only 24% of developers design APIs with AI agents in mind^[3]. In my view, plain pages with stable links, complete code samples and no content hidden behind a login are easier for people and for assistants to read; that is a judgement, not a measured result. Two extras are worth a look once that works: an llms.txt file, a proposed (not standard) Markdown guide to your docs for AI agents, which some docs platforms generate automatically^[6], and an MCP server, which lets assistants such as Claude, ChatGPT and Cursor call your product through the Model Context Protocol, an open-source standard for connecting AI applications to external systems^[7].

Example Co., step 3 Fictional

The reference page is generated from the API spec, but the task guides were written once and have drifted: two examples call a field that was renamed. The founder who writes the docs fixes those, adds a page on limits (“1,000 free pages a month, 20 requests a minute, here is what a 429 means”), and starts a dated changelog. She also moves the guides out from behind the sign-in wall. (Fictional.)

Do this

Open the three docs pages a new developer reads first. Run every code sample. Fix or delete anything that fails.

Step 4: Be where developers already look

Once the quickstart and docs work, the next question is where developers will find you. I would pick one place, do it well, and add a second only when the first runs without you.

GitHub

It is where developers already are. GitHub’s Octoverse 2025 reports more than 180 million developers on the platform, counting anyone with an account, and more than 4.3 million AI-related repositories^[8]. For you, that means a repository with runnable examples, a clear README that links the docs, and issues that get an answer within a day. A repository nobody answers does more harm than none.

One community you can staff

In the 2026 Stack Overflow survey, GitHub (69.5%) and Stack Overflow (68.6%) were the platforms respondents used most for technology content, and company-sponsored forums came near the bottom, at 8.6% (Figure 5)^[9]. You cannot be everywhere. Choose the one forum, Discord or issue tracker where your users already ask questions, and answer there for 30 days before judging it.

Content that solves a task

A post that shows how to extract line items from a PDF in 20 lines is more useful to a developer than a post about your vision. Write the task, the code and the result, and link the quickstart.

Open or closed

Founders ask whether to market open source or closed source. I have no sound study to cite on this, so it is my judgement: even if your service is closed, publishing the client libraries and examples as open source gives developers something to read, fork and trust, and it costs little. Whether to open the core product is a business model and licensing decision, not a marketing one, and it belongs with your lawyer and board.

Developer relations or a growth marketer first

I have no research to cite on this either. In my view the order depends on what is broken. If sign-ups do not become first calls, you need an engineer who writes docs and fixes the quickstart, which is the work of a developer advocate. If the quickstart works and few developers arrive, you need a growth marketer who can run search, content and partnerships. A growth marketer hired before the quickstart works spends salary on a leaky bucket. (Your first marketing hire covers when and who.)

Example Co., step 4 Fictional

After the fixes, the quickstart works but only a trickle of developers arrive. The founders pick GitHub: a public repository with the Python and TypeScript SDKs and five task examples. They commit to answering every issue within a working day and publish one task post a fortnight. They do not hire yet; the founder who writes the docs spends two days a week on this. (Fictional.)

Do this

Choose the one place developers ask about your category. Commit in writing to answering every question there for 30 days.

Step 5: Measure adoption, then answer “we’ll build it ourselves”

Measure adoption, not attention

Stars, page views and sign-ups feel good and tell you little. I would track five counts every week, in this order:

1. Sign-ups.
2. Developers who created an API key.
3. Developers who made a first successful call.
4. Developers still active in the second week.
5. Teams that started paying.

The drop between two stages tells you what to fix. A big drop between sign-up and first call is a quickstart problem (Step 2). A drop after the first call is a docs, quality or fit problem (Step 3). A drop before paying is a pricing, limits or approver problem (Step 1). To count these cleanly, set up your events before you launch; my tracking setup post shows how.

Developer CAC

Founders ask what a good developer CAC is. I have no sound public benchmark to give you, and I would distrust any figure quoted without a method. Work it out from your own numbers: add what you spent to bring developers in (including the time of the person doing it, valued at a fair cost) and divide by the new paying teams from that period. Then compare it with what a paying team is worth, using the Unit Economics Calculator.

The “we’ll build it ourselves” objection

Technical buyers often say it, and they are sometimes right. Do not argue. Offer a tally they can fill in with their own numbers: engineer weeks to build, ongoing maintenance, and the cost of getting quality to the level they need. Then offer a small pilot so they can compare on their own files. If the volume is very large or the documents are unusual, building may be the right choice, and saying so earns you trust.

Example Co., step 5 Fictional

In the last quarter Example Co. counted 2,000 sign-ups, 1,300 API keys, 300 first successful calls (15%), 120 developers active in week two and 6 new paying teams. It spent an assumed $12,000 that quarter (about $3,000 of hosting for the free tier and about $9,000 as the value of the docs founder’s time), so its developer CAC was $2,000 per paying team. A paying team brings about $4,800 a year, and at an assumed 70% gross margin that is about $280 a month, so payback is about seven months. If the same quarter had converted at the new quickstart’s target of 45% making a first call, with the later rates unchanged, there would be about 18 paying teams and a CAC near $670. That is a target, not a result. When a prospect says “we’ll build it ourselves,” the team sends a tally built on the prospect’s own assumptions: at an assumed $15,000 a month for a loaded engineer, a month and a half to build plus one day a week of upkeep for the rest of the year comes to about $54,000 in year one against about $4,800 for a typical paying team. The offer is a 30-day pilot on their own files. (All fictional.)

Do this

Write your five-stage funnel with last month’s counts, then circle the biggest drop. Fix that one before you spend on anything else.

Free tool

Work out developer CAC and payback

The free Unit Economics Calculator turns your spend, new paying teams and gross margin into CAC, payback and lifetime value, so you can see whether the funnel you just wrote pays for itself.

What changes by stage?

• Pre-seed — The founder answers every question and writes the docs. One quickstart, one repository, one community. No hire.
• Seed — Add someone who owns docs and community (a developer advocate or a technical writer) once the quickstart works and you have a funnel to measure. Add a growth marketer when sign-ups, not first calls, are the problem.
• Series A and B — Keep the self-serve path and add a route for approvers: security answers, procurement papers, a named contact. Larger buyers need the approval path Twilio’s filing describes; build it before the first big deal needs it.

What mistakes should I avoid?

• Putting the docs behind a sign-up form.
• A quickstart that needs a call, a sample file from another page, or a sales rep.
• Claims the product cannot reproduce in a notebook the developer can run.
• Counting stars or sign-ups as adoption.
• Hiring developer relations before there is a working quickstart.
• Letting issues and questions sit unanswered.
• Arguing with the “we’ll build it ourselves” objection instead of showing a tally.