The content strategy to turn your feature releases into AI citations and signups

Make the company easy to understand

Positioning comes first because everything downstream repeats it: every page, article, Reddit comment and launch post, and the brief you fill for every release in Step 5. Developers decide in seconds whether a tool is for them; LLMs decide from whatever sentence describes you most often across the web.

Write three artifacts before any content ships:

1. A one-sentence category statement in the form "X is a [category] for [who] that [does what], an alternative to [the two names they already know]." Convex's reads: an open-source reactive backend for writing server functions in pure TypeScript, an alternative to Firebase and Supabase for TypeScript and React teams. The comparison anchors matter more than the adjectives.
2. A use-case list by audience, not by feature. DeepInfra's buyers split into ML engineers, startup CTOs and indie developers; each searches for a different problem (GPU pricing, model benchmarks, OpenAI-compatible endpoints).
3. A competitor set you will name out loud. Build your competitor set based on your real competitors as well as your search-engine competitors — they may not compete for your customers, but they likely cover the same content topics and compete for the same SERP real estate.

Put the category statement on the homepage, the docs landing page, the GitHub README and the founder's LinkedIn headline, word for word. Consistency across sources is what makes an LLM confident enough to repeat it.

This might already exist in your head, but writing it down is extremely helpful for writers, audiences and — most importantly — LLMs.

We keep all three on one page, the positioning page, and every later step checks against it: the feature page's one-sentence description (Step 3), the brief and the announcement (Step 5), and the launch-week check (Step 8).

Decide what kind of release this is

The first thing we decide on every release is which kind it is, and we decide it before anyone opens a doc. We use three kinds, with a test for each:

Then we write the release calendar from the engineering roadmap, a quarter out, with the kind marked on each row. Marketing follows engineering dates here, not the other way round, and the calendar is what lets us prepare pages (Step 3) before the feature exists rather than after the announcement has gone out.

We add one more test in some categories: will a competitor ship the same thing this week? If yes, the release is a race, and the deadline collapses from "when it is ready" to "the same day as the announcement." I cover that case in Step 12, because it is where our strongest evidence comes from. For most launches, most of the time, the three rows above are enough.

Pro tip: in our experience founders over-count full launches and engineers under-count them. We break the tie with the test in the first row. If a developer could not do something new in a day because of it, it is not a full launch, however long it took to build.

Prepare your content before your public release

If a page does not exist, search and AI assistants assume the feature does not. Launch posts are time-stamped and sink; a feature page on a stable URL is what gets found and cited six months later. So we build the page first, and the announcement points at it, not the other way round.

What the feature page carries

In the order a developer reads it. Developers skip the marketing paragraph and read the table and the code; so does the assistant about to summarize you. We write those first.

Which supporting pages, and when

We do not build all five for every launch. We pick the ones that match the questions developers and the assistants are asking (Step 4 is how we find out).

We do the keyword research a week out, from the queries in the right-hand column with the product's names filled in.

AI visibility: pick the prompts this launch has to win

Keyword research tells us what people type into Google. It tells us nothing about what they ask ChatGPT, Perplexity or Gemini, and for a developer-tools launch that is now the question that matters. When a developer asks an assistant whether your product does X, or where they should run a model, the answer is a yes, a no, or a competitor's name, and the launch content decides which. So before we build the pages in Step 3, we decide which prompts this release has to win and build the pages against that list.

Three types of prompt, and a page for each

We recommend three types of prompt per launch, and we create a new page for each core prompt rather than hoping the announcement covers it. The announcement never does; it is dated and it sinks.

We weight the shortlist prompts highest. A yes/no prompt gets you confirmed; a shortlist prompt gets you recommended, and that is where a launch turns into a new customer.

How we find the prompts

• Start with the people who asked for the feature. The sales calls and tickets that requested it are phrased the way buyers phrase it, and the assistants get asked in the same words. "Can it read a passport MRZ" is a prompt; "document data extraction capability" is not.
• Reuse the shape from the last three launches. The prompts for a new model look like the prompts for the previous model with the name changed. We keep the list and fill in the blanks.
• Ask the assistants what they get asked. Put the feature name into ChatGPT and Perplexity and read the follow-up suggestions; they are a cheap view of the real question set.
• Keep it to five to ten. Fifty prompts per release is a dashboard nobody reads. Five to ten, weighted toward shortlists, is a list someone acts on.

Write the announcement from a brief, not from the pull request

Launch posts drift furthest from the positioning, because they get written last, by the person who built the feature, from the PR description. Our fix is a six-field brief, filled from a 25-minute interview with that engineer, and an announcement we write from the brief in the positioning language. The engineer does not write; they answer questions and check the code.

The announcement is those six fields in that order, with the demo embedded. We record the demo once, with whoever can do it in one take, and cut it to 60 seconds for X. Nothing else about the post is clever. "What you can do now" beats "what we shipped" every time, and the limitation paragraph is the one developers quote back approvingly.

Pro tip: we have someone who did not build the feature run the "how to try it" step before publishing. If it takes them more than five minutes, the post says "in five minutes" and is wrong, and the first comment will say so.

Choose content types that earn thought leadership

The brief from Step 5 is raw material for more than the announcement. A full launch can become several pieces, and the formats you pick decide whether it gets read, shared and cited, or sinks with the post.

The test for every piece is the same: is it opinionated, and has an expert verified it? Pass both and the format barely matters. Fail either and no format saves it.

Original data is the format nobody can copy

You are sitting on data no competitor has: what your users actually do, which models or frameworks they pick, where requests fail, what pricing looks like at real volumes. Anonymize and aggregate it ("across 40M requests last quarter, 62% of teams using X also used Y") and you have a piece that gets quoted. If you do not have the volume yet, run the test yourself: benchmark five providers on the same workload, time ten SDKs on the same device, and publish the method with the result. Both travel further on Reddit than anything else you will write, because they teach something and the brand is incidental to the finding.

No data of your own yet? Borrow a public dataset and do the explaining. Benchmarking sites publish raw comparison data that almost nobody reads in full: for DeepInfra we took artificialanalysis.ai's model comparison data (speed, price, quality scores across dozens of models and providers) and wrote it up for developers choosing a model, with the trade-offs spelled out and the source credited. The data was public; the interpretation was the content.

Build a template for the releases that repeat

Some launches are one-offs. Most are not: the tenth integration, the fourth SDK, the new model of the week. For anything we will launch more than four times, we hand-write the first four and extract a template from them; from the fifth on, the brief plus the template produce the draft. The engineer fills the fields, the template holds the structure and the voice, and one of us reads the output before it goes live.

We build the template in a tool we control. We use AirOps for templated volume and Claude for one-off drafts; whichever AI builder your team already has works, as long as the brief and the fields go in and a draft comes out with every step visible. Then our editing pass, which is not optional: we strip the model's meta commentary ("in this article we will…"), verify every number against the brief, three rounds, because the model will round, convert or helpfully update a figure it was not given, rewrite the passive voice, and break any sentence over 40 words. It takes us under an hour for a set of pages, and skipping it is how a wrong price ends up on the page developers compare you on.

The launch week, with an owner per row

We run a launch as a checklist that starts a week before the release and ends two weeks after it. We wrote it once, put a name on every row, and run it on every full launch without re-deciding anything.

The row most teams skip is the internal linking, and in my experience it is the highest-leverage ten minutes in the table. A new page nobody links to is invisible to the crawler and to the assistants; five links from pages Google already visits daily is the difference between indexed this afternoon and indexed next week.

Where it goes, under whose name

The announcement is one URL waiting to be found until it is posted where developers are. We put the same launch out in five forms on the same day, because that is how it gets found, discussed and cited, and each form feeds the others: the Reddit thread links the page, the X thread sends the founder's followers to both, and an assistant that sees the feature described in five places treats it as established.

Our rule across all of them: real names. Developers trust the engineer who built it and the founder who bet on it, and they can tell a company account from a person in one line. Reddit has stricter rules than the rest; Step 10 covers them.

Show up in Reddit communities

Reddit is where developers research tools before they ever reach your site, and it is a primary source for Google's AI Overviews, ChatGPT and Perplexity when they answer "which API should I use". One channel reaches the buyer directly and shapes what the models say about you. No other channel in Step 9 does both.

The communities that matter (r/LocalLLaMA, r/LLMDevs, r/MachineLearning, r/typescript, r/webdev and the niche subreddit for your stack) are the most hostile to marketing on the internet: strict moderation, astroturf detection, and users who call out a promotional post in a thread that then ranks on Google for years. A generic Reddit playbook gets you banned in a week.

1. Map the subreddits and the threads. List where your buyers ask questions, pull the recurring problems and competitor mentions, and set up monitoring so you see a high-intent thread within hours, not when it has 200 comments.
2. Earn trust before mentioning the product. Answer technically and completely; mention your product only where it is the honest answer, and name alternatives when they fit better. Publish inside the subreddit too: build guides, benchmark threads, model deep-dives that earn upvotes on merit (more on what works below).
3. Engineer the search placements. Target low-competition threads you can rank with, and go for the top comment on threads that already rank; Google pulls top comments into the SERP description. Reddit's own search is the third surface, roughly 80 million searches a month.

What got our accounts banned, and what worked instead

We learned this the expensive way: early on, many of our accounts were banned for content that was, in hindsight, promotional. A banned account takes its posting history and every placement it earned with it.

The build guides worked best. The shape is a complete, working build with the client as one named tool among several, with the code and the trade-offs:

• "How I built a document-parsing pipeline with Postgres, S3 and [client]"
• "Running Llama on a budget: a full setup with [client] for inference"
• "A production checklist for KYC onboarding, with [client] for document capture"

Developers upvote them because they can copy them, moderators leave them up because they are education, and the mention survives because the build earned it.

Run this under real names: DevRel, the engineer who built it, the founder, from accounts with real posting history in the community. Say who you work for when you mention the product. One rule: no account ever posts something an engineer at your company would not sign.

After launch day: links, mentions, and keeping it alive

Mentions beat links. When a developer asks an assistant whether your product does X, the answer is assembled from the comparison lists, roundups and threads the assistant trusts; your own feature page is the least of it. In our tracking, a plain-text mention in a "best tools for X" article that already ranks is worth more than a backlink from a site nobody reads.

The honest caveat: earning those mentions is slow. Getting added to a roundup that already ranks means finding the author, writing the ask, and waiting weeks for an editor who may never reply, and a launch does not have weeks. So we run two tracks in parallel: the slow outreach that pays off over a quarter, and the fast channels that put the launch in front of developers and in the assistants' source set within days.

The fast track: communities and distribution platforms

We recommend working with communities like Reddit and distribution platforms like Medium, dev.to and Substack to get reach and quick mentions in the first week. Each one is a place developers already read, each one is crawled and cited by the assistants, and none of them needs anyone's permission.

Republishing is the point, not a shortcut. The same integration guide on your site, on dev.to with a canonical, and summarized in a Reddit answer is three mentions of the feature in three places the assistants read, in one week, from one piece of writing. We set the canonical tag so the search credit stays with your page.

The slow track: the lists that already rank

• We reach out to the roundups and comparison articles that already rank for the category, asking to be added as one entry with the real price and the real limitation. We keep the list from launch to launch; the same ten articles rank every time, and the editors who added you once will add you again.
• We update your own comparison and "best of" pages the week it ships. A "best X providers" page on your own site that does not mention this week's feature is telling the assistant you do not have it.
• Consistency across surfaces. We check that the feature's name, price and limit read the same on the page, in the docs, in the changelog, in the README, in the dev.to copy and in the Reddit answer. Assistants gain confidence from agreement across sources and lose it from a stale price in one of them. It is the Step 1 rule for the category statement, applied to one feature.
• A quarterly "what changed" round-up, one line per release, linking to each feature page. It is the page that catches "what does [product] support," and it is the cheapest page we build.

We track the launch prompts from Step 4 in PromptWatch until the product is in the answer, and after, because the next release moves the answer again.

When it's a race: how DeepInfra launches a model a week

Everything above assumes you set the pace. Some categories do not let you. DeepInfra hosts 100+ models and adds a new one most weeks, and so do Together AI, Fireworks, Groq, Replicate and Novita, usually within hours of the same model lab's announcement. The feature is a commodity before the announcement thread has cooled. What separates the providers is which one developers find, and which one the assistants name when someone asks where to run it. That is a race, and we run it on content.

When we started, a new DeepInfra model page took days to get indexed. By the time Google saw it, the comparison lists and the Reddit threads had formed around Together AI and Replicate, and the AI answers followed them. The content was fine; the pipeline was slow, and in a race slow loses regardless of what you wrote. What we changed is the same process as the rest of this guide, compressed to a day:

• We do everything that can be done before the model exists, before. We rebuilt the crawl infrastructure so a page published at 10am is indexed by the afternoon; we keep templates with the fields blank; we pick keywords the moment a model is rumoured, from the pattern of the last ten releases; the outreach list is ready.
• On launch day we fill fields. The main model page and the supporting bundle (Step 7) go live the same day as the announcement, from one brief, with internal links from the five highest-traffic pages.
• Then two weeks of mentions. We answer the "where can I run [model]" threads in r/LocalLLaMA, r/LLMDevs, r/DeepSeek and r/openrouter completely, every provider named, within hours. We reach out to the "best providers for [model]" roundups that already rank. We post the benchmarks piece where the model is being discussed.

It is the strongest evidence we have for the whole process, because the pace leaves nowhere to hide. If your category works this way, the deadline for every row in Step 8 moves to the same day, and the preparation in Steps 3 and 4 becomes the job.

Score every launch the same way

One sheet, one row per release, the same columns every time. We score a launch on three things, in the order they happen: did search see it, did people visit it, and did the assistants pick it up. Then whether any of those visits turned into a conversion. The point is not the numbers on any one launch; it is seeing launches side by side, which is what tells you which kind of release deserves a full launch next time and which part of the kit is slipping.

Three sources, one row

Then the conversions

Visits are the input; the row is not finished until it says what the visits did. We tie every launch page to the conversion events from the companion guide (signup, API key, SDK install or download, with landing page and source), and add one column for the launch itself: first use of the new feature by a new account, which is the API call with the new model string or the flag turned on. The ratio that matters is conversions per 100 sessions on the launch pages. It is usually higher than the site average, because a developer who searched for the feature by name arrived ready to try it, and when it is lower than the site average the page is missing its next step.

The sheet also settles arguments for us. When a launch underperforms, the row shows whether search never saw the page, visitors came and did not convert, or the assistants never picked it up. Those have different fixes, and without the row I have watched teams pick the fix that is most fun.

Who owns what, and when to hire

A launch process survives on names, not goodwill. We give every release one named owner, and split the rest so that nobody's part takes more than an hour or two once the templates exist.

The first full launch takes three times that, because the templates and the outreach list do not exist yet. By the fourth it is routine. When it stops being routine, that is the signal we tell clients to hire on: releases coming faster than one owner can run them alongside their actual job, rows in the scorecard going empty, or the sheet showing that launch pages are now a main source of conversions and the mention work is what moves the AI column, so it deserves more than the hour it gets.

The first marketing hire then inherits something we rarely see a first hire get: a release calendar with the kind marked on every row, a template set, an outreach list with live contacts, a Reddit presence under real names, and a scorecard with a row for every launch. Their first quarter is adding to it, not building it.