Positioning decides what is true about you and how a skeptic tests it. This section is about the surface that claim lands on: what goes above the fold, in what order, next to which proof, and which link the developer takes to leave the marketing behind. A correct positioning laid out badly still fails, because a developer gives the page one scroll and a back button.

Decide who the page is for

The most common homepage failure is not bad copy — it is a page addressed to two people at once. The developer who will evaluate you and the manager who will pay for you want opposite things: one wants to be running in five minutes, the other wants the migration story, the cost at scale and who owns it in production. Written for both, the page reads as generic to each.

Pick one, and route the other. The pattern that works is a developer-first homepage with an explicit door for the buyer — a “for teams” or “enterprise” page linked from the nav — rather than a homepage that averages the two audiences into adjectives. The choice is a positioning decision made visible; if you cannot say which of the two the homepage serves, that is the finding.

The first screenful

Three things have to survive a five-second scan: what this is, what job it does, and how to start. Everything else is scroll.

  • The headline names the job, in the words the developer would use searching for it. If a reader cannot guess what the first API call does after reading it, rewrite it before you touch anything else on the page.
  • The visual shows the product, not an abstraction. Real code, the actual UI, a terminal doing the thing. Gradient blobs and isometric illustrations are what you ship when the product does not demo well in a rectangle, and developers read them exactly that way.
  • The code sample is the demo. Six to ten lines that would genuinely work, in the language most of your audience uses. It does more than the headline and the visual combined, and it is the single most-copied element on a dev tool homepage.

The navbar is a routing decision, not a menu

For a developer, the nav’s job is to get them out of the marketing site as fast as possible. Docs, the repo, and pricing are the three destinations that matter, and they should be reachable without a dropdown. A nav where Docs is buried in a “Resources” flyout beside three webinars is telling a developer their path is not the one you optimised for.

Two things worth deciding deliberately: whether the repo gets a nav slot (it should, if the repo is any good — see the repo as a front door), and whether “Pricing” is a real link or a euphemism for a contact form. The second one is read as an answer to “is this for me”.

One primary call to action, and one for the not-yet-ready

Most dev tool pages have too many. Choose the single action that starts the path to value — usually “read the quickstart” or “start free”, almost never “book a demo” — and let it be visually unambiguous everywhere it appears.

Then add a transitional CTA for the majority who are not signing up today: the docs, the playground, the sandbox, the free tool. It costs nothing, it collects nobody’s email, and it is what converts a developer who found you six months before they had the problem. A page with only a high-commitment CTA loses every visitor who was going to become a user later.

Put the proof next to the claim it supports

A logo wall at the bottom of the page is decoration. Proof works when it sits beside the specific claim a skeptic doubts: the latency number next to the performance claim, the named engineer’s quote beside the reliability claim, the live download count beside “widely used”.

Prefer numbers a reader can go and check — a public download count, a star-history graph, a status page — over testimonials they have to take on faith. That is the verifiable-proof rule applied to page layout: a logo shows that someone signed once, a live counter shows the thing is used.

The two pages most teams get wrong

Pricing. Put a real number on it, and where billing is usage-based, put the cap in the same eyeline as the meter — the runaway-bill fear is what kills usage-based signups, and it has to be answered on the page rather than in a FAQ. What the number should be, which shape it takes, and what else now belongs on that page (the training-data policy, the enterprise door) is pricing and packaging’s subject; this section’s only claim is that the page is a conversion surface, not a legal one.

Comparison pages. A developer comparing you to an incumbent is going to read a comparison; the only question is whose. A comparison page earns the traffic when it is accurate enough that the competitor could not file a complaint about it — name what they do better, keep the feature table current, and date it. The version that lists forty green checks against forty red crosses converts worse than none, because it tells a skeptical reader the whole page is a sales asset.

The minimum viable version

If you are pre-traction and choosing where to spend, the order is: a homepage that names the job with a working code sample, a quickstart that ends in a success, a real pricing page, and a changelog that proves the thing is alive. Everything else — the customer stories, the solutions pages, the resource centre — is worth building only after those four are true.