Developer experience

Developers do not "adopt an API." They adopt a path from curiosity to production: sign up, authenticate, make a first successful call, paste a snippet into their app, handle errors, graduate from test mode, and keep the integration alive through your versioning choices. If that path is slow, confusing or hostile, no amount of endpoint completeness saves you.

Stripe and Twilio did not win because they had more HTTP verbs. They won because time-to-first-call and day-two operability felt respectful. A mediocre API with great docs and logs often beats a clever API that leaves integrators blind when something fails at 2 a.m.

Developers as users

Your user is often tired, context-switching, and judged by whether their product ships on time. They optimize for:

• Time to first hello-world — minutes, not days.
• Trust — test mode, clear billing, no surprise charges.
• Debuggability — request IDs, logs, actionable errors.
• Stability promises — versioning and deprecation they can bet a business on.
• Fit into their stack — idiomatic SDKs, not only raw HTTP.

Think of the first hour after signup the way a consumer PM thinks about activation: every extra form field, ambiguous region picker or undocumented error code is a drop-off.

Instrument each step. A dashboard that shows "signups" but not "first successful POST /v1/..." is a vanity dashboard.

Walking through a stuck first call

Your "first call" doc says install SDK, create a key, run client.messages.create(...). You measure median time from key creation to first 2xx: 47 minutes. Support shows people stuck choosing a region and pasting the secret into the wrong env var.

You add a "copy .env" button, default region, and a CLI login that writes the file. Median drops to 9 minutes. Same API — different product.

Internal platforms count

If you own an internal platform API, the same rules apply: your "customers" are other squads. Time-to-first-call, versioning promises and error quality determine whether teams adopt your platform or shadow-build. Measure adoption of the blessed path and time for a new squad to produce a production service, not lines of platform code shipped.

Common mistakes

• Counting endpoints. Completeness does not save a hostile first hour.
• Vanity dashboards. Signups without first successful call hide the cliff.
• Ignoring internal adopters. Other squads are users too.

Check yourself

1,000 signups, 40 production calls. Marketing problem? Usually not. You have a DX cliff between key creation and first success, or between test mode and live.

Median time to first 2xx is 47 minutes. What do you fix first? The first-hour path: region picker, env vars, copy-paste. Same API, different product.

Key takeaways

• DX is a product: optimize time to first successful call and the path to production.
• Instrument every step from docs to live traffic. Signups alone are vanity.
• Internal platforms follow the same rules. Measure blessed-path adoption.

Further learning

Next: API shape as UX. Map: developer and API products.