How do developers research new tools?

In a fairly fixed loop: read the documentation to judge the mental model, inspect the repository for signs of life and maintainer temperament, check community answers for real-world experience, then install the tool and test the claims directly. Growth work in devtools means being strong at every station of that loop.

Why do docs matter so much for devtools growth?

Documentation is read twice — by engineers deciding whether to adopt, and by AI assistants assembling answers to how-to questions in the category. Thin or unreadable docs lose both audiences at once, which makes the docs site a primary demand surface rather than a support asset.

Can marketing actually help a developer tools company?

Yes, but mostly around the loop rather than inside it: surfacing engineering evidence, keeping docs-grade content honest, participating transparently in community threads, and measuring whether assistants and evaluators encounter the product. Faking any station — especially community presence — costs more than it gains.

What should a devtools company measure?

Whether the research loop completes. Externally: which tools assistants name for the category's problems and whose docs get cited, tracked against a frozen benchmark that is re-scanned on a schedule. Internally: time-to-first-success in the trial and the station where evaluators exit.

The five growth questions for developer tools companies

Guide · Frameworks · 5 min read · last verified 2026-07-27

Reviewed before publication Editorial board Independent commercial review

In shortDevelopers research tools through a loop vendors do not control: docs, repository, community answers, then a trial. This edition threads the five growth questions through that loop and marks where marketing can and cannot intervene.

A developer tools company grows when working engineers decide, on their own evidence, that the product deserves a place in their stack. There is no separate buyer to charm: the person who evaluates a devtool is the person who will live inside it, and that person runs a research loop that marketing never controls — read the docs, inspect the repository, check what other practitioners say, then install the thing and see. A devtools growth plan is a plan for being excellent at every station of that loop, with an honest account of where marketing can intervene and where it can only prepare the ground. The flagship five-question framework still applies; what changes is that most of the answers live in surfaces owned by engineering, not marketing.

The loop runs whether you join it or not

Developer research follows a sequence so consistent it is nearly a protocol. An engineer hits a problem, asks an AI assistant or a search engine what exists, and collects a handful of names. Each name that survives the first glance enters the loop. First the documentation: is the mental model sane, does the API look designed or accreted, can I see my use case in the examples. Then the repository: is the project alive, how do maintainers respond to issues, what does the changelog admit. Then community answers: do real practitioners succeed with this, and what do they complain about once the honeymoon ends. Finally the trial: install it on a clean machine and find out whether the quickstart tells the truth.

Every station is a filter, and the loop is self-service by design. The engineer does not want a discovery call, will not trade an email address for a whitepaper, and treats a gated PDF as a small insult. This is what the first growth question looks like in devtools: you are not losing buyers in a funnel, you are losing them at a specific station of a loop you can observe from outside. Finding that station — the point where evaluators consistently exit — is the diagnostic that makes the rest of the plan honest.

Documentation is a demand surface

Docs are read twice. Engineers read them to decide; AI assistants read them to answer. When someone asks an assistant how to solve a problem in your category, the response is assembled from whatever documentation the assistant could reach and trust — and a thin, vague, or JavaScript-locked docs site loses both audiences at once. How JS rendering affects what AI can read applies with special force to docs frameworks that render content client-side, and the lesson of whether your help center affects AI answers extends naturally here: task-level pages are citation material.

The second growth question — what should we create — is answered mostly inside the docs site. A quickstart per major use case. Examples that run as written. A limitations page that states plainly what the tool does not do, which earns more trust from this audience than any superlative could. Comparison pages that concede real trade-offs. In devtools, content that lives outside the docs mostly exists to support what lives inside them.

The repository is a storefront window

An engineer reads a repository the way other buyers read reviews. Commit cadence says whether the project is alive. Issue threads say how the team treats users under mild stress. Open issues are not damning — ignored ones are. The tone maintainers take with a confused first-timer is, for many evaluators, the most persuasive page about your company anywhere on the internet.

Marketing cannot fake any of this, and should not try. What it can do is surface it: release notes written like documentation rather than press releases, changelogs that name what broke and what was fixed, engineering posts that show how the team thinks. The repository also feeds the same answer surfaces the docs do — issues and discussions on GitHub get indexed, quoted, and summarized alongside everything else.

Community answers are the loop's long memory

Questions answered on Stack Overflow and in practitioner forums persist for years, and Q&A sites shape AI answers far beyond their own traffic. A tool whose threads are full of unanswered questions has a reputation problem no campaign can outspend; a tool whose maintainers show up under real names and answer thoroughly compounds trust every month.

This is the third growth question — how do we reach the right people — resolved without advertising. Reach in devtools is presence in the specific threads where evaluation happens: the forum where your category argues, the answer under the exact error message your near-adopters are hitting tonight. The discipline of showing up in communities buyers trust is enforced ruthlessly by this audience: identify yourself, answer the question fully, take criticism without spin, never astroturf. One exposed sock puppet costs more than years of honest answers earned.

The trial audits every claim you made

Time-to-first-success decides most devtools evaluations: the stretch between installing the product and watching it do something real. The fourth growth question — who does the work of executing — has a distinctive shape here because the answer is a pact between engineering and marketing. The quickstart is product work. Error messages are marketing copy, read at the exact moment trust is being decided. Docs, sandboxes, and free tiers belong to both departments or they belong to no one, and the plan should say so explicitly: engineering owns the loop's stations, marketing owns the approaches to them, and both own the handoffs.

Measuring a loop you watch from outside

The fifth question — did any of it work — is where devtools growth becomes empirical. Take the questions evaluators actually ask, freeze them into a benchmark, and re-scan on a schedule: which tools do assistants name for your category's problems, whose docs get cited, which community threads are quoted, where your name appears and where it is absent. Magrios exists to run exactly this loop — the frozen benchmark and the scheduled re-scan — so that changes in what assistants say can be attributed to what you shipped rather than to hope.

Pair the outside view with the inside one: where installs stall, where quickstarts fail, where evaluators exit. Movement in both is the only evidence this audience would accept from you, so it should be the only evidence you accept from yourself.

The allergy is information

Developers' allergy to marketing speak is not a style preference; it is a filter tuned by years of reading claims that did not survive contact with a terminal. Adjectives read as evasion. Specificity reads as respect. The devtools companies that grow are the ones that treat the allergy as free editorial guidance: strip the plan of superlatives, put the evidence where the loop already looks, and let the product's honest surfaces — docs, repository, answers, trial — carry the argument.