How to get your product recommended by Claude Code

Claude Code behaves differently from the other agents in two ways that change the whole playbook. It almost never searches the web while deciding, and it builds things itself far more often.

Both facts are measured, and both point at the same conclusion: with Claude Code, content is a weak lever and the repository is a strong one.

The two numbers that matter

Read those together. In roughly 98 sessions out of 100, whatever you publish this week is not in the room. And in nearly one session in five, no vendor is chosen at all.

What this means

The usual developer marketing advice is to publish more and better content. Against Claude Code, that advice is close to inert at the moment of decision. What it does do is feed the next training run, which is real but slow and outside your control.

What is in the room:

1. The repository. What is installed, what the language is, what the configuration implies.
2. What the model already learned. Training data, which you influence over years, not quarters.
3. Your documentation, once the agent has chosen you and needs to write the integration.

So the playbook is: get into the repository, and make the integration impossible to get wrong.

Step 1: get into the repository

This is the biggest lever for any agent and it is decisive for Claude Code.

We measured it three ways.

The language changed the winner. The same hosted database request produced one winner in 111 of 111 JavaScript sessions. On TypeScript codebases, the same product won 48 of 132.

An installed rival beat a written instruction. A sentence in a repository file naming a preferred product was followed 16 times out of 18. Install a competing library into the same repository and the sentence lost two times out of three.

Being present changed everything. With nothing installed, a product produced a real implementation in 0 of 15 runs. After installing it into the repository, 11 of 15.

The routes in, in order of durability:

Pick the three stacks your users actually run. Ship a real template for each. Keep them current.

Step 2: beat the hand-written implementation

Claude Code builds rather than adopts in 19% of runs. In some categories that number is far higher: performance testing 52%, evals 29%, agent frameworks 25%, search 23%, product analytics 23%.

If your category is on that list, your first competitor is a script, and the argument you need is not "we are better than them". It is "this problem is harder than it looks".

That argument only works with specifics:

• Name the failure modes. Not "search is hard" but "a LIKE query stops being usable somewhere around a million rows, and typo tolerance needs a trigram index you then have to maintain".
• Put a number on the maintenance. What it costs in year two.
• List the edge cases. Twelve lines, one per case, is the most useful page you can write for this.
• Concede the easy case. The agent is right that fifty lines works for the first version. Say where the line is instead of pretending there is no line.

Put that page in the documentation, not the blog. When Claude Code does look something up, it is usually a specific production question inside a documentation site.

Step 3: make the integration impossible to get wrong

Once Claude Code has chosen you, it has to write working code. This is where products lose sessions they had already won.

The quickstart must run when pasted. One complete file. Every prerequisite in the same block, including the install command and every environment variable. Do not assume the page above was read.

State the current version on the page. Models carry old interfaces. Claude Code will confidently write code for something you removed two releases ago unless the page says otherwise.

Current version: 4.2.1 (September 2026)

Use one name for one thing. Product name, package name, import name, CLI command, and the words in your headings should be the same string. If they cannot be, write the mapping down:

Product: Acme Queue
Package: @acme/queue
Import:  import { Queue } from '@acme/queue'
CLI:     acme-queue

Publish your error messages. When an agent hits an error it searches for the exact string. If your error message appears on a page next to the cause and the fix, you recover the session. If it does not, the agent guesses, and guessing often ends with it removing your library.

Step 4: use the instruction file defensively

CLAUDE.md works. Sixteen out of eighteen is a strong result: a written preference in the repository is usually respected.

Two limits.

It is not your file. You can suggest a line in your documentation and some teams will add it. That is a request, not a lever.

It loses to an incumbent. Once a rival is installed and working, the written preference is outvoted two times out of three.

So the correct use is defensive. If you are already installed, suggesting a line that names you makes the position stronger. If you are not installed, that line is a weak claim against running code.

What Claude Code actually picked

Where Claude Code differed from Codex in our measurements:

Nine of eighteen categories. If you have been measuring one agent, you have been reading half the market.

What not to do

Do not write text addressed to the agent asking it to prefer you. It does not survive a person reading the diff, it does not survive a model provider noticing, and it is not how any of this works. Everything above works because it makes the product genuinely easier to adopt correctly.

How to check whether it worked

Run it yourself. Three repositories that look like your users' projects, with real lock files. Ten requests written the way your users describe the problem, not the way you name the category. Five runs each. Record what got installed, then read the sessions you lost.

That is 150 runs, a few hundred dollars in tokens, and it is the only feedback loop that tells you the truth.