Every section that follows assumes you know who it is for. Most developer marketing that fails did not fail at the tactic; it addressed a “developer” who does not exist, in a company shaped nothing like the one that will actually pay. This section is the cheapest work in the guide and the most skipped.

Three people, not one

The word “developer” hides three different readers, and a page written for the average of them reaches none.

  • The user is the engineer who will evaluate you, integrate you and live with you. They read the docs before the homepage, judge you on time-to-first-success, and are the only one of the three who can say whether the thing works.
  • The buyer is the person whose budget it is — an engineering manager, a platform lead, a CTO, sometimes a CFO. Above a certain price the user is your champion, not your buyer, and the buyer asks questions the user never will: what does this replace, what does it cost at scale, what happens when it goes down, who is accountable when it does. A champion who cannot answer those four loses the argument in a meeting you are not in. So arm them: a page that says what you cost at volume, a one-line security and compliance answer, a migration story, an honest uptime record. The mistake is not having the material; it is putting it on the homepage where it displaces the developer’s own questions. Give it a door of its own and link to it — the website covers where.
  • The account is the company shape that makes the first two true: the size, the stack, the regulatory weight, the build-versus-buy culture. This is the ideal customer profile, and it is a smaller set than “companies with developers”. Pick the three characteristics that predict who gets the most value from you — stack, team size and one pain is a common trio — and write them down, because your entire go-to-market is downstream of them.

The same headline cannot serve the user and the buyer. An indie hacker spending personal money evaluates you on a weekend, alone, and wants a working result before dinner. A platform engineer on a team spends the company’s money, has to fit you into an existing stack, and needs organisational buy-in and a switching-cost story before anything ships. One wants “running in five minutes on the free tier”; the other wants “here is how you migrate, what it costs at scale, and who owns it in production”. Decide which developer a given page, tutorial or launch is for, and say so.

Developer-first or developer-plus

The second decision is whether developers are your market or your route to it. A developer-first product (a database, a deployment platform, an observability tool) is bought by the people who use it, and the guide’s surfaces — docs, activation, the repo — are the whole funnel. A developer-plus product (a payments API, an email service, a search box for someone else’s shop) is used by developers on behalf of a business whose buyer may never see a line of code, and the developer’s job is to make the integration invisible to that buyer. The distinction decides what “activation” means, who the pricing page is for, and whether DevRel is a growth engine or an enablement function. Most companies are one or the other; the ones that try to be both usually have two products.

The job they are hiring you for

Developers evaluate tools by the job to be done — send transactional email, add auth without building it, search across my data — and they describe that job in their own words, long before they know your category exists. The fastest research in this guide is reading those words back. Search your category on Hacker News, Reddit and Stack Overflow and collect how developers describe the problem in their own posts; if your headline uses none of those words, it was written for an investor. The job also names your real first competitor.

”I can build this myself” is a competitor

For most developer products the incumbent is not another vendor but the evening a senior engineer spends building a worse version. That alternative is free at the point of decision, defensible in a meeting, and flattering to the person proposing it, and in 2026 it got cheaper: Retool’s survey of 817 builders (late 2025; Retool’s own customers included, so read it as a vendor’s panel) found 35% had already replaced at least one SaaS tool with a custom build and 78% expected to build more in 2026 — with 36% of respondents being software engineers and the rest operations, product and data people who can now build too. Position against it honestly: name what the homegrown version costs in the second year (the on-call, the upgrades, the person who leaves), and make the first success so fast that the build-it-yourself estimate looks expensive by comparison. A comparison that pretends the alternative does not exist loses to it.

The population you are sizing against

The market is large and, for the first time, growing slowly. SlashData put the global developer population at 47.2 million in early 2025, up from 31 million in 2022 — but the annual growth rate fell to 10% from 21% the year before, the amateur segment shrank by more than a million in a year, and nearly all the growth is professional developers (36.5 million, up 70% since 2022). Its later Q3 2025 estimate moved the headline to 48.4 million — a 2.5% step in six months, which is the plateau continuing, not ending — and the professional/amateur split has not been republished with it, so the shape above is the last one with numbers behind it. Two consequences for a marketer: the hobbyist top of funnel that made a free tier “free marketing” is contracting, so a plan that counts on it should be re-costed; and the professional majority is reachable through work-shaped channels — the stack they already run, the assistant in their editor — more than through the hobby-shaped ones.

The same professional majority now works with an AI tool beside them and does not trust it. Stack Overflow’s 2025 survey (33,000-plus responses to the question) had 84% of developers using or planning to use AI tools, up from 76% the year before, while more actively distrusted the accuracy of those tools (46%) than trusted it (33%), and 3% reported “highly trusting” the output. Read that as a buyer profile: the developer you are selling to is being handed your product’s description by a machine they do not believe, and will go to your docs to check. What the docs have to be when the reader arrives that way is the answer engines section’s subject.

Research it in a week

None of this needs a quarter or a budget. The cheap methods, roughly in order of effort:

  • Read the words back. The search above. An afternoon.
  • Ask your best users the switching question. “What were you doing before, and what made you change?” The answer is your positioning stated by someone with no incentive to flatter it, and it is routinely better than the copy on the site. Five calls.
  • Ask the ones who left. The churned user knows the build-versus-buy math better than anyone still paying. Three calls, and the honest ones will tell you which competitor is the homegrown one.
  • Instrument “how did you hear about us”. A free-text field at signup is the only attribution this audience will not block, and over a quarter it tells you which of the three readers you are actually reaching. Measurement says what to do with it.

Write the result down in one page — the user, the buyer, the account, the job in their words, the alternative you lose to — and put the date on it. Positioning is written against that page, and every section after it is cheaper when the page exists.