Developer experience (DX) is the sum of every friction and delight a developer meets while trying to build with you — from the first npm install to the third production incident. For a developer product, DX is the growth engine: great DX turns a curious signup into a paying, retained, referring integration; poor DX loses them silently, and they rarely tell you why.

Time-to-value is the number that matters

Adoption is gated by how fast a developer reaches a moment of real value — a successful call, a deployed app, a passing test against your API. Measure it as time-to-first-success (or time-to-first-hello-world) and time-to-value (the first useful result, not just any result). Shortening these does more for growth than almost any campaign.

Treat every minute of that path as a conversion surface: account creation, API key generation, environment setup, the first request, the first success. Each step loses people. Instrument each one.

The developer funnel

A useful frame — adapt the stages to your product:

  1. Discover — hears about you (search, peer, content, event).
  2. Evaluate — reads the docs, scans the pricing, checks GitHub and the community.
  3. Sign up / install — creates an account or pulls the SDK.
  4. Activate — reaches first success, then first value.
  5. Integrate — ships something real to production.
  6. Habit / expand — uses it routinely, adopts more surface area.
  7. Advocate — recommends it, contributes, brings it to the next project.

Most teams over-invest in Discover and under-invest in Activate → Integrate, where the real leaks are. A developer who signs up and never reaches first success is a marketing cost with no return.

Friction to hunt down

  • Signup and key friction. Every required field, email verification, and manual approval before the first call bleeds activation. Delay what you can until after first value — the logical end state is deploy-before-signup, which shipped as a real product surface in August 2026 when Railway made deploys accountless (build first, claim the project within 60 minutes). Neon extended it to the agent in September 2026: Claimable Neon lets a coding agent provision a Postgres project with no account at all, capped at 100 MB, 1 GB of transfer and 72 hours, for a human to claim by link later — so “sign up” is now a step that can come after first value, and for a machine reader it usually should. Agent rails has the protocol.
  • Environment pain. Broken installs, version conflicts, unclear prerequisites. A containerized or hosted sandbox removes a whole class of drop-off.
  • Bad error messages. Errors are documentation at the worst possible moment. An error that says exactly what went wrong and how to fix it is a retention feature.
  • Stale examples. Sample code that no longer runs is worse than none — it breaks trust precisely when the developer is committing.
  • The second-day cliff. Great quickstart, then a wall when they try something real. Make sure the path from “hello world” to “production” is paved.

Deprecation is a DX event

The free tier, the open-source core and the self-serve path are pricing and packaging decisions, and they have their own section. What belongs here is what happens when any surface a developer built on changes underneath them.

A free tier is a contract, and developers build on it literally — hardcoded model names, assumed endpoints, cron jobs that call you at 3 a.m. Changing or sunsetting one is a deprecation event, not a pricing tweak: give it a date, email the people whose integrations will break, return an error that says deprecated rather than a silent 404, and offer a migration path. The failure mode is rarely public outrage; it’s a quiet re-anchoring on “this vendor breaks things without telling me” that surfaces at the next build-vs-buy decision. Sunsetting a free tier is usually defensible — doing it silently is what burns the trust. The same applies to any surface developers integrate against, and the length of the window is itself a signal of who the schedule serves: as of mid-2026 the credible benchmark is measured in months — the MCP spec deprecates with a twelve-month minimum, HashiCorp gave its hosted Vagrant registry a phased five months (announced 2026-08-03; new boxes stop October 1, support ends November 2, operations end December 31, 2026, with a self-hosting guide) — so a retirement measured in weeks (GitHub Models’ six, Spark’s 27 days) reads as a warning label on everything else you ship. Length is not the whole grade, though: mechanics can make a short window serve developers better than a long silent one. GitHub Models’ final month included two scheduled brownouts (July 16 and 23, 2026) — deliberate, dated interruptions that returned errors so teams found their hidden dependencies while there was still time to fix them. A brownout is a fire drill you run for your customers; a long window nobody hears from until the shutoff is just a longer surprise. And watch for compounding clocks: when one sunset breaks integrations before another product’s own notice even starts — Spark apps lost their llm() function the day GitHub Models died, five days before Spark’s own deprecation was announced — the effective window is the shortest dependency’s, and that’s the one developers experience.

DX is where marketing, product, and engineering share a scoreboard. If activation is falling, no amount of top-of-funnel spend fixes it.