Your Documentation Is Your Funnel (And the One Page Nobody Writes)

Web3 Advisory — Thu, 30 Jul 2026 20:46:27 +0000

Most companies file documentation under engineering and marketing under marketing, then wonder why
the funnel leaks.

For a developer product, the docs are the funnel. A developer evaluating you spends about thirty
seconds on your homepage and then goes straight to the docs. Everything after that is decided there,
by a person you will never speak to, who will not fill in a form to tell you why they left.

We have run content and social for developer-infrastructure companies whose customers were engineers
building on top of them. The pattern was the same every time: the landing page got the credit, the
docs did the work.

Four things, and never mix them

Documentation fails most often by conflation. There are four distinct kinds and they have
incompatible jobs.

Quickstart. One page, one goal: something working in under fifteen minutes. No architecture, no
philosophy, no menu of options. Copy-paste blocks that run as written.

Guides. Task-shaped. "How to do X." Written for somebody with a job to finish today.

Reference. Exhaustive and boring. Every parameter, every return value, every error. This is
consulted, not read, and it should be optimised for someone scanning it in a hurry.

Explanation. The why. Design decisions, tradeoffs, the mental model. This is the one that turns a
user into an advocate, and the one nearly everyone skips.

A quickstart that pauses to explain your architecture has failed at being a quickstart. A reference
page with a warm narrative voice is unusable at midnight when someone is debugging. Keep them
separate and each one gets to be good at its own job.

The details that actually decide it

Every code sample must run exactly as written. Not close enough. If it depends on a variable
defined three sections earlier, it will fail, and you will not hear about it. Test your samples in CI
like code, because they are code.

Show the errors, not just the happy path. What does it look like when it breaks, and what does
that message mean? This is the most-searched and least-written kind of documentation in existence.

Make it searchable and deep-linkable. People arrive from a search engine mid-problem, not through
your nav. If a section cannot be linked to, it cannot be recommended.

Say when it was last updated. Stale docs are worse than no docs, and a visible date lets a reader
judge for themselves instead of guessing.

Never gate it. No login, no email capture, no "request access." A gate on documentation reads as a
sales process attached to a product that cannot be evaluated.

The page nobody writes

Here is the highest-leverage documentation most companies never produce: one page per common error
message, titled with the literal text of the error.

Somebody hits ECONNREFUSED at two in the morning, pastes it into a search engine, and lands on your
page explaining what causes it and how to fix it. You have just been maximally useful at the moment
of maximum frustration, to a person who was about to give up on you.

That page will outperform a quarter of campaigns, and it costs an afternoon. Your support inbox
already tells you which ten errors to write first.

Where the rest of the effort should go

Once the docs work, the channel map for this audience is narrower than most marketing plans assume.

Worth real investment: technical posts with substance (the hard problem you actually solved, with
the code and the dead ends, not a listicle), open source that is genuinely useful on its own
rather than a thin wrapper advertising the paid thing, and being present where the problem is
discussed: Stack Overflow, the subreddit, Discord, GitHub issues. Answer the question, help the
person, and mention your product only when it is honestly the answer. That last one is slow,
unglamorous, and the highest-trust channel available to you.

Mostly theatre: paid social to developers, sponsored enthusiasm from influencers, booth-only
conference presence, gated whitepapers, and swag treated as a strategy rather than a thank-you.

Order matters more than breadth

The sequence is not optional, because doing it out of order wastes the earlier work.

Fix time-to-first-working-thing. Nothing else pays off until this is good.
Write the quickstart and the reference. That is the minimum for someone to evaluate you alone.
Add error pages and guides for the top ten things people get stuck on.
Start showing up in communities, helpfully, without pitching.
Publish technical posts about real problems.
Then consider talks, video, comparison pages, and the rest.

Most companies start at step six and cannot work out why it is not landing. They are marketing a
product nobody can get running.

The whole playbook

This is the documentation and channels part of The Developer Marketing Playbook: why marketing to
engineers is structurally different and the four normal-marketing assumptions that sink you, the full
channel map with what each channel is actually good for, the launch sequence for a developer-facing
product, the specific writing and behaviour habits this audience punishes and rewards, the web3
traps if that is your world, and which popular metrics are actively misleading for developer
products.

Written from running social and content for developer-infrastructure projects including Ankr, zkSync
and SKALE.

Get The Developer Marketing Playbook ($39). 12-page PDF,
dense, no padding.

There are no growth hacks in it. They do not work on this audience, and trying them costs you the
trust you needed.