Time to first successful call, when the developer is an agent

Time to first successful call is the oldest useful number in developer marketing. How long from arriving at the documentation to one call that works.

It still predicts adoption better than anything else. What changed is who is doing the arriving, and how they behave when it goes wrong.

The behavioural difference

That difference changes what the metric means.

The last row is the whole thing. Your failed onboardings used to be visible as tickets and forum posts. Now most of them are silent.

Where the time actually goes

Rank your own quickstart by these, in order of how often they cost a session.

Prerequisites that are not in the block. An environment variable named on a different page. An install step assumed from the previous section. An account or dashboard action that never appears in the code.

A fragment instead of a file. Three lines from the middle of something, with no imports and no way to run.

A stale example. The interface changed and the page did not. The generated code fails, and the failure looks like your product rather than your page.

A name mismatch. Product name to package name to import name. Every gap is a guess.

An unclear error. 400 Bad Request teaches nothing. An error that names the argument and the expected format gets the next call right.

The version of the metric that works now

Old version: instrument your documentation and measure the median minutes to the first successful API call.

That still works for humans and it misses everything above, because the agent that abandoned never made a call to measure.

New version, and it is not a dashboard:

1. Take three repositories that look like your users' projects, with real lock files.
2. Give a coding agent a one-line request your product answers, written the way a user would describe the problem rather than the way you name the category.
3. Watch where it stalls.
4. Do it five times per combination. The same agent on the same repository disagrees with itself about a quarter of the time, so one run is noise.

What you get is not a duration. It is a list of the exact steps where sessions die, which is more useful.

The fixes, in order of payback

One complete file. Install command, every environment variable, every out-of-code step as a numbered comment, and a line at the end that confirms it worked.

// 1. Create a project at https://acme.dev/new and copy the project ID
// 2. npm install @acme/queue
// 3. Set ACME_API_KEY and ACME_PROJECT_ID in your environment

import { Queue } from '@acme/queue'

const queue = new Queue({ apiKey: process.env.ACME_API_KEY })
await queue.send('welcome-email', { to: 'someone@example.com' })

console.log('Sent. See it at https://acme.dev/dashboard')

The current version on the page, in the text. Not only in a sidebar widget.

A test key that works without an account, even rate limited. Every step outside the editor is a place a session ends.

Errors that contain the fix. The 'since' argument must be an ISO 8601 date such as 2026-09-03. You sent '3 days ago'.

A confirmation the agent can check. An agent that can verify the call succeeded stops. One that cannot keeps changing things, and often changes the thing that was working.

Why this is worth more than it looks

Of the products in our data that reached an agent's shortlist and were never chosen, four of the five recurring causes are on this page. They are not preference losses. They are integration failures, and they happen after the product has already won the argument.

Mailgun was raised in 97 of 208 email sessions and adopted in none. Cursor put it on the list in 85% of its email sessions. That is not an awareness problem.

See the products coding agents consider and never choose.

The test to run this week

Open an empty project. Paste your quickstart. Run it, using nothing you know about your own product.

Most quickstarts fail that. It is an afternoon to fix and it is the last step of every session you nearly won.