The fastest way to lose a new developer is not a bug. It is a choice they were not ready to make.

I have spent the last few weeks reading developer quickstarts the way a new developer would: open the docs, follow the first page, and try to reach one working result. The pattern that kept repeating had nothing to do with broken code. The code mostly worked. The problem came earlier, in the first screen, when the product asked the reader to decide what kind of product it is, which edition to use, or which path to take, before anything had run.

This is a docs-based first-run review. I reviewed the quickstart and docs as a new developer would, and I did not run every product end to end in production. The findings below come from those docs, not from a production deployment. What follows is the pattern across them, and what tool makers can do about it.

1. Tell me what you are, in one sentence, before you tell me what you can do

Typesense is the clearest example. Its docs position it as Algolia and Pinecone and easier Elasticsearch at once. That leaves a new developer with a real question and no way to answer it in 60 seconds: is this a search engine, a vector database, or a retrieval platform for AI apps? The answer matters, because each of those choices implies a different data model, a different query pattern, and a different reason to pick it over the thing it claims to replace.

Speakeasy has the same split on its first screen. It presents as an AI control plane and governed MCP gateway, and also as its original SDK and CLI line. A developer who arrived to generate an SDK cannot tell whether that is still the product, or whether the product has moved on and the SDK is now a side feature.

Zilliz asks for a similar decision before the quickstart. Milvus, Zilliz Cloud, and Vector Lakebase sit side by side, and the reader has to choose between them before running a query. MotherDuck does it with audience instead of product names: an analysts thesis sits next to an agent-builders story, plus a hybrid local and cloud model, before the first query. In each case the docs are not wrong. They are just asking the reader to do the product positioning work that the company should have done already.

A first-run page has one job: get a stranger to a working result. Every sentence that makes the reader stop and classify the product is a sentence working against that job.

2. Do not fork the path before the first success

E2B calls itself the AI Agent Cloud, but its docs give Claude Code a pre-built template and first-class treatment on the template path. A developer building with a different agent has to guess whether the product is general or Claude-shaped. That guess comes before the first sandbox. Worse, the Template quickstart asks for a custom template first: image, environment variables, files, start command, and separate dev and prod builds, before any sandbox runs from it. The default sandbox quickstart does not ask for this, so the build-system first run sits on the template path, not the default path. On that path, the first run is not a sandbox. It is a build system.

Browserbase has a similar fork, in a different shape. One API key spans browsers, search, fetch, functions, and identity, plus Stagehand, Director, Agents, and MCP. There is no default path. A new developer has to pick a surface before they can pick a task.

Langfuse asks for the same kind of choice, only with more parts. Its first run sits inside a five-part loop, with OpenTelemetry versus integrations versus self-host versus Cloud as the setup decision. The tracing idea is clear. The way in is not.

Hex shows the fork at the level of the user, not the API. Coders and business users share one workspace, with no sample-data first run that lets either side see what the product does for them. Dify shows it at the level of entry points: too many starting places for a new developer to pick from before anything runs.

Slack Bolt for JavaScript, which has genuinely strong docs, still forks before the first handler. The guide offers Socket Mode and Request URL as two parallel tracks. Socket Mode is recommended for beginners and needs a bot token plus a separate app-level token with the connections:write scope. The Request URL path needs a public URL and is described as more useful for deployed apps and Marketplace distribution. A developer who starts on the beginner path has to redo the setup decision at ship time. The guide documents both paths well. It does not resolve the fork.

Letta is the sharpest version of this problem. Its own announcement says package names shifted to clarify MemGPT agents versus the Letta framework, yet a new developer still has to untangle MemGPT as a paper, a pattern, and a codebase from Letta before learning what a stateful agent is in plain English. And the Agent SDK quickstart is JavaScript and TypeScript only, so a Python developer has to use the App Server WebSocket protocol directly. The naming change was meant to clarify. The first run still makes the reader do the untangling.

3. What a clean first run looks like

Jira Cloud is a useful contrast, and not because it is frictionless. Its REST API v3 changes the representation of the most common field: a plain string description, exactly as every other JSON API teaches, fails, because the description must be a JSON document tree in Atlassian Document Format, while single-line fields on the same issue still accept plain strings. That is a real friction, and it hits every integration.

But Jira does one thing right that the products above do not. Version 2 and version 3 offer the same collection of operations, so migration is representation only, and the intro page states the document-format scope field by field instead of hiding it. There is one API, one path, and one clearly stated rule. The developer still has to learn a format, but they do not have to choose a product, an edition, or a deployment path first.

That is the standard to aim for: one obvious path, one working result, and any necessary choice stated plainly on the page where it matters.

A short checklist for tool makers

If you maintain a developer product, read your own quickstart as a stranger and ask three questions.

First, can a new developer say what your product is, in one sentence, after the first screen? If the answer needs three comparisons, cut two of them from the first page.

Second, can they reach a working result without choosing between two paths, two editions, or two audiences? If not, pick the default for them and put the alternative on a second page, with a clear note on when to switch.

Third, does the quickstart ask for setup that belongs after the first success? A custom template, a second token type, a schema definition, or a deployment decision is not a first step. It is a second step wearing a first-step label.

The products in this piece are not bad products. In most cases the docs are detailed, the features are real, and the teams behind them clearly care about developers. The failure is narrower and more fixable than that: the first page asks the reader to do product strategy before it lets them do engineering. Fix the first page, pick a default, and let the first run be a run.

Forefront publishes a weekly first-run teardown of a developer tool, built from the same docs-first method used here. You can read it here: https://forefrontshowofficial.substack.com