API-first: Time to first hello world

There is one number that decides whether a developer adopts your API, and it is not on most dashboards. It is the time from creating an account to seeing your product do something real: a test charge processed, a message sent, a row returned.

Call it time to first hello world. Everything a developer-tools company does about marketing, positioning and sales enablement is downstream of that number, because the evaluation is over before any of it gets a chance to matter.

You can measure it this afternoon, on your own product, with a stopwatch.¹

What is API-first self-serve?

API-first self-serve means a developer can sign up, get credentials, and make a working call without approval from anyone at your company or theirs. The documentation is the demo, and the sandbox is the trial.

What separates this from its neighbors is how much a stranger can confirm without permission:

Time to first hello world, and why it is the whole game

A developer evaluating your API is not deciding whether to buy. They are deciding whether to keep going for another ten minutes. Every step between signup and a working response is a place that decision gets made again, and each one loses some of them.

This is why the metric is not “time to integrate” or the usual time to value. Those are outcomes. Time to first hello world measures the evaluation, and the evaluation is the part you lose.

The things that inflate it are all mundane, and all fixable:

A verification step before credentials. Every hour between signup and a usable key is an hour in which a developer solves the problem another way.

Examples that do not run. A snippet with a placeholder that is not explained, or that assumes a setup step documented on another page, fails silently and reads as your product being broken.

A sandbox that is not real. Test mode that returns canned responses teaches nothing about whether the thing works. Twilio’s version is instructive: a trial account gets a real phone number sending real messages, to numbers you have verified. Restricted, but not simulated, which is the distinction that matters. The developer sees the actual thing work.

It helps to know what a reading means. Minutes is winning. Hours is surviving. Days is losing, because by then the developer has either solved the problem another way or stopped being the person who cares. Those are orders of magnitude rather than targets, and the only one that matters is which band you are in.

The credit card is the procurement bypass

An API-first product is bottom-up adoption with nothing standing in the way: a developer with a company card can start without asking anyone. There is no vendor review, no security questionnaire, no budget line. By the time anyone in finance notices, the product is in production and the conversation is about invoicing, not evaluation.

That has a design consequence most teams miss: your first transaction should be small enough to be invisible. A starting spend that a developer would need to justify puts you back in the approval process you just escaped, which is the entire advantage gone.

It also has a limit. This works until the point where somebody does a security review, and at that point you need SSO, audit logs, data residency answers and a contract. Companies that treat those as an afterthought get stuck: enormous developer adoption, and deals that die in review. Adoption and procurement are two different sales, and the second one is not optional. The working shape is hybrid: self-serve does the adopting, and a human arrives later for the expansion, aimed by usage the product already recorded.

Two things make the land-and-expand version of this work. The first is consolidation: one integration that replaces a dozen point integrations is an easier decision than one that adds a thirteenth, and it is why the pitch is usually about what a developer gets to delete. The second is that each new source, destination or endpoint they wire up deepens the integration, so expansion is something the customer does to themselves, not something you sell them.

It also pays to be the easy choice for a very small company. Single-country, single-currency, one-developer setups are where vendor selection takes minutes instead of months, and some of those companies become the enterprises you would never have won in an open evaluation.

One variant changes what you should optimize. Some APIs spread through products their end users never see. Bank-linking infrastructure is the clearest case: a great many people have connected a bank account inside an app like Robinhood, Venmo or Coinbase without ever learning the name of the company (Plaid) that actually made the connection. The developer integrates you, and the people who benefit have no idea your company exists. Breadth of coverage then becomes the thing a competitor cannot copy quickly, and your integration count matters far more than your brand. You are chosen by engineers and evaluated by nobody else, which is comfortable right up until a competitor is chosen the same way.

Who API-first self-serve does not work for

The pattern needs four things at once, and each has an obvious way to fail. The person evaluating has to be somebody who writes code, not a manager who will delegate it. The product has to do something useful in a single call, not after configuration. A response has to demonstrate the value, rather than value appearing weeks later once data accumulates. And a developer has to be legally able to start alone, which regulated data usually prevents.

The pattern’s home categories are payments, communications, infrastructure, bank connections and model providers. What they share is not that they are technical; it is that a developer can prove the value alone, in an afternoon.

What to measure after the stopwatch

Time to first hello world tells you about the first ten minutes. Three internal comparisons tell you about the rest.

1. What share of signups ever make one successful call? This is the real activation rate for an API product, and a product-qualified signal you get without asking, since nobody makes a call by accident. Anyone who never made a call never evaluated you.
2. Where do developers stop between first call and production? Authentication, error handling, rate limits, webhooks. Look at support tickets and public questions about your API; the cluster is your actual documentation gap.
3. Do accounts that reached production in week one retain better than those that took a month? If they do, speed is not just a conversion lever, it is predicting the quality of the account, which changes what your onboarding is for.

Time your own hello world

1. Time your own first hello world, properly, as described above. Write the number down. It is the most useful thing on this page.
2. Copy-paste every example in your docs and run it, in every language you claim to support. Broken examples are read as a broken product, and they rot quietly whenever the API changes.
3. Remove one approval step between signup and a usable credential. Look for the one that exists for reasons nobody remembers.
4. Check your minimum first spend is small enough that nobody needs permission to try you. Usage-based pricing does this structurally, not by discounting: paying for what you actually consumed removes the commitment anxiety from an evaluation, because there is nothing to commit to.
5. Find out whether your enterprise answers exist yet. SSO, audit logs, a security questionnaire response. If they do not, your best adopters will stall at exactly the moment they try to make you official.

One developer, working alone, needing nobody’s cooperation: that is the reader this whole page has been written for. Plenty of products cannot be evaluated that way at all, because they do nothing until other people show up, which is either the strongest moat in software or a story a company tells itself. Far more companies believe they have network effects than have them, and there is a one-day test that settles which group you are in.

Updated August 2026