// growth
Marketing for API and Developer-Tool Companies
If the keys you issue go quiet, the answer is in your quickstart. An engineer copies the snippet, runs it, reads whatever comes back. That is the evaluation, finished before your homepage is opened and before anyone on your side knows it began. So this is mostly a product job: the docs, the first request, the error you return when the key is wrong. We write those and ship them as code.
This page covers selling to engineers who read docs before they read copy. It does not cover the repository as a channel. Stars, README positioning, release notes and open-source community work belong to our GitHub service, measured on its own number. If your buyer is a committee and not the engineer who will use the thing, that is SaaS marketing.
Why the documentation is the marketing
An engineer evaluating an API runs a short and unforgiving loop. Find the endpoint. Copy the example. Run it. Read the failure. Everything they will ever believe about your product is decided inside that loop. Before a salesperson is involved, and often before they have told a colleague they are looking.
No campaign reaches into that loop. The documentation does, because the documentation is the only thing present. So we treat it as the asset:
- The quickstart has exactly one conversion event, which is a successful response on the reader’s own machine, and everything in it is measured against that.
- The reference is generated from the spec, so it cannot quietly disagree with the API it describes.
- Errors are copy. A 400 that names the field, the reason and the fix is the cheapest support you will ever ship.
- Examples live in CI. An example that stops compiling should fail your build, not a stranger’s afternoon.
Docs are now also read by machines
A growing share of first contact with your API is an engineer asking an assistant how to do something, then pasting what it returns. Documentation that states the answer first, names the version it applies to, and is served as HTML gets reused correctly. Docs assembled after hydration do not. Documentation that buries the answer under positioning gets summarised into something wrong, and the engineer blames your API for the result. Being cited inside generated answers is a separate discipline with its own page under search visibility. What belongs here is writing docs that survive being read out of context.
Why we measure activated keys
Signups measure curiosity. An activated key is the first honest number on the board, because someone got far enough to authenticate and do something real.
We instrument four events and report against them: signup, API key created, first authenticated request, first production call. The gaps between them tell you which problem you have. A cliff between signup and first request is a documentation or onboarding failure. A cliff between first request and production is usually pricing, limits or a missing capability, and no amount of writing fixes it. Reporting sessions and pageviews hides both.
Developer relations without pretending to be you
We can run the function: technical posts under our own names, answers in the places your users already ask, and launch material. We also write benchmarks with a published method and a reproducible script. That is real work and it moves real numbers.
It is also not a permanent substitute for someone in-house. Communities notice who is still there in a year. We would rather set that expectation at the start of an engagement than at the renewal conversation.
Four things we turn down
Bought upvotes and reviews, and accounts run by us that pretend to be your engineers. That is the cheap version of this job, it is the version that gets found, and the people who find it are your buyers.
Benchmarks whose conclusion was chosen before the measurement. One competitor with a reproduction script is enough to end a devtool company’s credibility, and it does not come back.
Opinions ghostwritten under your CTO’s byline and presented as community. We publish technical work under our own names, or we do not publish it.
Documentation written around a defect. When the obstacle is the API itself, the recommendation you get is an engineering one. The writing project would usually have been the easier thing to sell. You get the engineering one anyway.
What you get
- A documentation set written and shipped into your repository as pull requests, covering the quickstart, the reference and the failure cases
- Sample applications and SDK snippets held in CI, so an example that stops compiling fails your build instead of a customer's afternoon
- Instrumentation of the path from signup to first authenticated call to first production call, so activation can be read instead of guessed
- Error responses and status pages rewritten as product copy, because that is where an evaluating engineer spends their worst ten minutes
- A self-serve evaluation path with working limits, key rotation and reset behaviour, so nobody has to book a call to try the thing
- Technical writing published under real names, including benchmarks and teardowns where we can show the method
- A monthly readout against activated keys and first successful calls, including the experiments that changed nothing
How it runs
- 01
Use the product cold, as a stranger
We sign up with no help from your team and record every place we stall, in order, with timestamps. Your own engineers cannot run this test honestly any more, because they know the workarounds and stop noticing them.
- 02
Instrument activation before changing anything
We instrument four events: signup, API key created, first authenticated request, first production call. Without them you cannot tell a positioning problem from a documentation problem, and the two have opposite fixes.
- 03
Fix the documentation as code
Changes arrive as pull requests against your docs and your examples, reviewed by your engineers. Documentation rot is a deployment problem, not a writing problem. Anything not held in CI drifts away from the API within a release or two.
- 04
Earn attention where engineers already are
Technical posts, answers to real questions, launch material and benchmarks with a published method. The people who choose your API arrive from a peer, a search or a post that solved the exact problem they had. So that is where the work goes.
- 05
Report against activation, not traffic
Traffic can double while activation stays flat. That pattern means the first ten minutes are broken, and the top of the funnel is fine. Reporting that hides it wastes a quarter before anyone notices.
Questions we get asked
- How is this different from the work you do on our repository?
- This page owns the whole job of selling to an engineering buyer: the docs, the quickstart, the evaluation path, the technical writing, the launch. The repository work is a separate service because it answers a different question. This page asks whether an engineer can get your product working. That one asks whether they ever encounter it in the first place. Plenty of API companies eventually want both. We still scope them apart, because they are judged on different numbers (activated keys here, installs that are still running a week later there).
- Is this content marketing with an engineering vocabulary on top?
- No. Most of what we ship is product surface, not campaign material. The quickstart, the error strings, the sample apps and the sandbox limits. The articles matter, and they are the smaller half. A blog in front of a broken first-call experience delivers more people to the same wall.
- Our documentation is owned by engineering. Will this cause a turf war?
- It usually does not. We work inside their repository and their review process instead of forking the docs into a marketing CMS. Every change is a pull request your engineers can reject. If your team would rather we wrote specifications and left the merging to them, that works too. It is slower, and more of it gets dropped.
- Can you get us on the Hacker News front page or a launch-platform leaderboard?
- We can write the post, pick the framing and choose the day. We cannot promise the placement, because it is decided by votes nobody selling you a launch has a hand on. Two methods would put a hand on it. Buying votes, and running accounts that are not people. Both break those platforms' rules and are routinely detected. It is also the wrong goal. A launch spike that produces no activated keys is a good afternoon and nothing else.
- We have no free tier. Does that matter?
- Yes, and it is the most expensive thing on this list. If an engineer cannot make a successful call without a sales conversation, you lose most of the evaluations you never hear about. If the pricing cannot change, the work shifts to the sandbox and the documented examples. They have to be realistic enough to stand in for it. We will tell you that this is a workaround.
- Do we still need to hire a developer relations person?
- Eventually, yes. We can run the function, publish under our own names and hand over a working motion. A community wants someone whose job is your product, and who will still be there next year. We would rather say that at the start than at renewal.
- What if the real problem is the API itself?
- Then we say so, and the recommendation will be an engineering one. A resource shape that takes three calls to do one thing cannot be documented into acceptability. Neither can an auth flow that fails silently. We also build software, so we can fix it, but we will not sell you a documentation project to avoid an awkward conversation.