How to get high‑quality developer content from a small marketing team

How we did it at DeepInfra and LlamaIndex.

Marketing to developers comes with its own set of challenges. The audience is smart, detail-oriented and constantly evaluating new tools, the keywords are low volume and don’t always appear in traditional search tools, and the first marketing hire has to do the work of 5 teams (not even 5 people).

We love this industry, professionally and personally, and believe it’s uniquely well suited for a strong content, SEO and AIO strategy. This is the playbook we run for clients like Convex, ReadMe, DeepInfra and Microblink (with some minor variations for each one).

I’ve ordered it so each step builds on the step before, and at the end your marketing team should be able to get a variety of content ideas, content workflows and high-quality output from materials you already have.

The model: One writer, a team’s worth of content

You do not need a content team. You need one developer-author whose hours go only where judgment is required, and four things around them that multiply every hour. Everything in this guide is one of those four multipliers or the measurement we use to prove they work.

The plan we follow:

• one author at $250 to $800 an article,
• two expert pieces a month,
• plus templates that produce dozens of pages a month at the cost of a PM’s inputs and a day a week of the author’s review.

Step 1: Make the company easy to understand

Positioning comes first because everything downstream repeats it: every page, article, Reddit comment and launch post, and the trial brief you hand an author in Step 2. It is also your recruiting pitch. The developer-authors you want choose products they can explain in a sentence and argue about; a vague category statement loses them before the trial task. Developers decide in seconds whether a tool is for them; LLMs decide from whatever sentence describes you most often across the web.

We 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.

We 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 in our experience writing it down is extremely helpful for writers, audiences and — most importantly — LLMs. Countless times we’ve seen solutions pages miss obvious features or industries; if it’s not written on your website, LLMs will not pick up on it, and may even tell customers you do not have these features if they ask for them directly.

On a real account: Microblink

Three products, three audiences (developers, compliance officers, enterprise security buyers). Our keyword research split developer-intent from compliance-intent queries, and each intent got its own /services/ page in that audience’s vocabulary: KYC API for developers (SDK size, latency, response payload) next to automated KYC for compliance; liveness detection and selfie verification as one capability under two buyer searches; banking onboarding as the industry entry point. Same product, different first sentence per reader. Case study

Step 2: Start with one developer-author, in week one

Start recruiting authors early — it’s hard to find the right fit, especially when working with freelancers. We generally prefer working with contractors for technical content: our best fit is a working developer who blogs about tech on the side. There are quite a few of these writers if you’re willing to look hard enough.

Where to look

In my experience, the best technical writers are full-time developers who moonlight as writers. They have shipped the thing they are writing about, they often run their own blog, and they come with ideas. Search dev.to and Medium for your topics.

Doing a generic Google search and looking for dev blogs is a great option too.

But do not post a generic “technical writer” job; you will get content marketers who need you to explain the product.

How to connect

This will be your biggest drop-off — we’ve sent dozens of invites on a single project, with most going ignored. So be determined: LinkedIn, email, Twitter, ask for an intro. Just sending one email, and you’ll likely be ignored.

And always lead with price to show you’re serious — there’s so much writing and link-exchange spam hitting their inbox that if you’re not showing a real business opportunity, you’re likely to be ignored.

Short and sweet is fine:

“Hi Roger, this is Kirill from AUQ — we’re hiring authors for a technical writing project for startup.com, we pay between $300 and $600 an article depending on experience and complexity, would you be interested in working with us?”

How to test

We always pay for a trial task. Give the author the category statement from Step 1, a sandbox account and one broad topic, and let them propose the outline and write the article themselves. You are grading three things:

1. Idea generation. Did the outline find an angle you had not thought of? An author who needs a brief for every piece costs you the time you were trying to buy back.
2. Expertise. Are the code samples runnable? Did they hit a real limitation of the product and say so? Developers read for the caveats.
3. Writing quality. Can a reader skim it? Are the claims verifiable?

Expect to trial three to five authors for every one you keep, and budget for it; that’s the ratio we see. Give kept authors a standing sandbox, a Slack channel with an engineer, and access to sales call recordings. The articles that convert are the ones where the author understood the product well enough to disagree with the marketing.

What a good author looks like

The trial task tells you whether they can write. Three other things tell you whether they will still be useful in month six:

• They bring their own expertise. They have opinions about the category before they know yours, and the article is better for it. An author who only reflects your docs back at you is a copywriter with a GitHub account.
• They are willing to interview your team. The best pieces come from a 30-minute call with the engineer who built the feature. Authors who want that call, and come with questions, produce content nobody else can.
• They will join editorial meetings. A standing call where authors hear what sales is hearing, what shipped, and what is coming. Authors who treat it as part of the job become a second set of eyes on the whole content program.
• They run their own tech blog. Best-case scenario: a working developer who already writes about your space on the side comes with a voice, a backlog of ideas and proof they can ship before they write a word for you.

What it costs

Expect $250 to $800 per article for a developer-author, depending on depth and how scarce the expertise is. The low end buys a solid tutorial from someone early in their writing career; the high end buys a benchmark piece or an architecture opinion from a senior engineer in a narrow field (ML infrastructure, security, distributed systems). A 1,500-word article with runnable code from someone who has shipped the thing usually lands in the middle. Pay trial tasks at the same rate as a finished article; a discounted trial attracts the authors you do not want.

On a real account: LlamaIndex

The document-parsing content needed authors with real OCR experience, so we went looking for them rather than for writers. We interviewed developers and developer-relations people, starting from a list of 30. Three made it through the trial and stayed. That ratio is normal, and it is why this is the first step.

On a real account: ReadMe

API documentation is a subject most freelance writers cannot cover credibly, so for ReadMe.com we recruited, tested and trained a dedicated external writing team rather than hiring generalists — 61 articles published or optimized in six months. Case study

Step 3: Put AI in the flow for templated content

We use AI for the content that has a fixed shape and a long tail, and keep humans on the content that needs an opinion. Lists, niche landing pages and glossaries are templated by nature; a thought-leadership piece is not.

How the two tracks work

The expert track is your developer-authors from Step 2. They write the pieces that need a point of view: release write-ups, benchmarks, opinion pieces, build guides. Nothing on this track is generated; the value is the author’s judgment and the fact that they ran the code.

The templated track is three pipelines that produce pages with a fixed shape. The author owns the template and the quality bar; a product manager owns the inputs, because the PM knows the feature set, the limits and what is true about the product today. The pipeline turns structured inputs into a draft page; it does not invent facts.

Pipeline	Page shape	Inputs the PM supplies	Example
Niche landing pages	“[product] for [framework]”, “[task] with [tool]”	Feature set, limits, a working snippet, the integration’s auth steps	“Document parsing for Next.js apps”, “Parse PDFs from SharePoint”
“Best of” lists	Comparison table with entity definitions and real numbers; your product as one honest entry	Competitor set, comparison criteria, verified prices and limits	“Best inference APIs for Llama 3 in 2026”
Glossary	Short definitional article, one term each	Term list, how the product relates to the term, a link to the relevant doc	“What is liveness detection?”

The author builds the pipeline before the pipeline writes anything

The output quality of a pipeline is set by whoever writes the template, which is why this is the author’s job and not the PM’s. The sequence we use, per pipeline:

1. Write four golden pages by hand, against the ICP research. Real pages, published, written for one specific reader (the engineer evaluating at 2am, the compliance officer, the CTO comparing vendors). They become the exemplars the model copies: structure, length, where the code goes, how a limitation is stated, what a comparison row contains.
2. Extract the template. From the four pages: the brief the model gets, the fields the PM fills, and a review checklist of what fails a page (a snippet that does not run, a number with no source, a claim the docs do not support).
3. Hand it to the PM. The PM fills the inputs for the first batch; the pipeline drafts; the author reads every one of the first four generated pages in full and fixes the template, not the pages.
4. Review by visibility, not by volume. After the first four, the checklist does the gating and the author reviews only the pages that earn impressions, clicks or AI citations. A page nobody sees does not need an editor’s hour; a page that starts ranking gets a full read the week it does. A failure on a reviewed page pulls its batch back through the checklist.

Budget two weeks of the author’s time per pipeline to build, then about a day a week across all three for the visibility-driven review. The rest of their time goes back to the expert track.

Tools

OK, we’ll skip the basics of project management — I’m sure you have that figured out.

The interesting stuff is what you’ll use to automate your templates and measure your results.

Number one: don’t rely on AI to build your templates — they should be based on your author’s original work. Pro tip: test a few different article structures to see which one ranks better, then use that as your template.

Tools like Profound and Surfer SEO will promise they can write your article for you… I don’t trust them.

So for us it’s usually a debate between two content production tools:

AirOps: we build our own detailed flow charts that clearly spell out intro, body 1, body 2, comparison chart, HTML table and so on. It lets us use different models for writing, control costs, add page scrapers and reference knowledge bases. It’s tedious, but gives you a lot of control.

Claude Code: we’ll build a similar flow in Claude, but it’s less controlled and Claude hides some of the magic under its hood.

If you want detail and control, go with AirOps. If you want speed, use Claude.

Guardrails: generated pages must carry something a model cannot invent (a real benchmark, a real snippet, a real limit); never publish a page that only restates the docs; noindex anything that fails review rather than deleting it, so the URL stays stable.

On a real account: fraud.net

We built three pipelines (niche landing pages, listicles with comparison tables, a category glossary), with every page read by an editor before publishing: 400+ pieces in six months, 1,230 AI Overview citations from a baseline of zero. Case study

On a real account: LlamaIndex

This is what the templated track looks like when it works. The /insights listicles and /glossary went from no traffic to 21% of the domain’s Google clicks in a year, the listicles are 11 of the 15 most-cited llamaindex.ai pages in AI answers, and those sessions produced 1,097 sign-ups in Q3. Templated pages convert when they land a developer on something they can run.

Step 4: Choose content types that earn thought leadership

The test we apply to 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.

Format	What it is	Why it works
Technical release write-ups	What shipped, why, benchmarks, migration notes	Timed to real demand spikes
Use cases with working code	“How we built X with [product]”, repo linked	Developers arrive with the product already installed
Build guides	Step-by-step tutorials for a job your buyers do	Captures intent-driven searches
Benchmarks and comparisons	Your tool vs named alternatives, with numbers	The format AI assistants cite most
Opinion pieces	A position on how the category should work	How you become the default; travels on Reddit and HN
Original data	Anonymized usage data from your platform, or tests you ran yourself	Nobody else can publish it; the most shareable format on Reddit because it reads as education

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.

Your engineers and your sales team are the sources nobody else has

The highest-quality material for the expert track is already inside the building; it just is not in writing yet. Engineers know what was built and why. Sales hears, every day, what real buyers struggle with, what they compare you to and the words they use for the problem. I’ve found a 25-minute interview with either produces a better piece than a week of desk research, and the author’s job is to ask the questions and run the code. The sources, and what each becomes:

Engineering source	Becomes
Changelog entry or release PR	Release write-up with the “why”, benchmarks and migration notes
RFC or design doc	Architecture opinion piece: the trade-off you chose and what you gave up
Incident or post-mortem	The most-shared engineering content there is, if the company allows it
Internal benchmark or load test	Original-data piece with the method published
Support tickets and Discord questions	Build guides and glossary terms; the questions asked three times are the backlog
Engineer’s conference talk	The article is the talk’s long-tail; the talk is the article’s distribution (Step 9)
Sales call recordings	The question asked in every call is a build guide; the comparison prospects raise is a “[product] vs [competitor]” piece in the buyer’s own words
Lost-deal notes	The honest “when not to use us” piece, which is the most trusted thing you will publish
Onboarding and support calls	First-week friction becomes the tutorials developers actually search for

How to run the interview

The author runs it, 25 minutes, recorded, transcript back to the author the same day. Schedule one engineer a month and sales every two weeks through the editorial call (Step 6). The questions differ by room:

Ask an engineer	Ask sales
What did you build, and what did you consider instead?	What question comes up in every call?
What broke or surprised you along the way?	What do prospects compare us to, and what do they say about those tools?
What number would you put on a slide about this?	Which objection do we lose to, and what do we say back?
What would you tell someone integrating this at 2am?	What did the last three deals we closed have in common?
What limitation do you wish was documented?	What words do buyers use for the problem that we do not use on the site?

Walk out with four things or the interview was not finished: one claim with a number attached, one limitation stated plainly, one quote worth printing, and the buyer’s words for the problem. Those four go at the top of the brief; the rest of the article is written around them.

DevRel owns getting the author into the engineering rooms, the marketing leader opens the sales ones (Step 6). Nothing here requires anyone to write; it requires 25 minutes and a willingness to be quoted.

The keyword volume problem, and where to find topics instead

Developer-specific keywords have low search volume. “TypeScript backend real-time sync” may show 40 searches a month; a keyword tool will tell you to skip it, and it would be wrong, because those 40 searches are your buyers and the long tail of similar queries is enormous. Use keyword tools to size clusters, not to find ideas. Your best sources are:

Set a cadence you can hold: two expert pieces a month beats eight generic ones. Fill the volume gap with the templated content in Step 3.

On a real account: LlamaIndex

The OCR and document-parsing cluster looked too thin to bother with per query. Once we built it out as a cluster, clicks on queries containing “ocr” went from 303 to 5,454 in a year and impressions from 4.8K to 551K. Judge the cluster, not the keyword.

On a real account: Convex and Microblink

Convex’s help center maps the whole TypeScript question space by intent, from language basics to backend patterns; the brand appears only where it is the honest answer. Microblink maps three formats to three intents: landing pages for use cases, articles for comparisons, glossary for definitions. Technical-term organic traffic rose 127%. Convex, Microblink

On a real account: ReadMe

For ReadMe.com, we split the roadmap by intent and format: knowledge-base entries for definitional queries (“api documentation format”), long-form articles for comparisons (“graphql vs rest”, “sdk vs api”), landing pages for buying intent, and a ~90-term API glossary underneath, grouped into clusters. The new library ranked for 333 keywords a month after launch. Case study

Step 5: Build explicit product, solution and feature pages

If a page does not exist, Google and LLMs assume the capability does not exist. Most dev-tool sites are a homepage, docs and pricing, and the team believes the rest is obvious. It is obvious to you. ChatGPT has only indexed what you published, and it will recommend the competitor whose site spells it out.

Page type	What it answers	Example from client work
Product page per product	“What is [product]?”	Microblink: separate pages for BlinkID, BlinkID Verify, BlinkCard
Feature page per capability	“Does [product] do X?”	DeepInfra: OpenAI-compatible API, dedicated GPU capacity
Model or integration page per item	“Does [product] support [thing]?”	DeepInfra: a page per model (Llama, DeepSeek, Mistral, Qwen) plus model-family pages
Solution page per use case	“[Product] for [job]”	Microblink: age verification for gaming, KYC automation for fintech, document scanning for travel
Comparison page per competitor	“[Product] vs [competitor]”	Convex vs Firebase, Convex vs Supabase
Integration page per connected tool	“[Task] with [popular tool]”	A document-parsing API: “parse PDFs from SharePoint”, “index Google Drive files”, “load Notion pages”
Pricing page with real numbers	“What does it cost?”	“Contact us” pricing gets left out of AI recommendations

Integrations: ride the popularity of the tools you connect to

If your product connects to other software, every connection is a page. Developers do not search for your product; they search for the job plus the tool they already use: “parse PDFs from SharePoint”, “sync Postgres to a vector store”, “Slack alerts from Datadog”. The popular brand carries search volume your own name does not have yet, and an LLM asked “how do I do [task] with [brand]” will cite whichever integration page explains it with working code.

Build one page per integration, titled with the task and the brand, with a code sample, the auth steps, the limits, and a link into the docs. Order the backlog by the partner tool’s popularity, not by how proud you are of the integration. A hundred of these pages is normal for a data or workflow product and is exactly the templated work Step 3 is for.

Two rules that save months later: give every page a stable URL now, because launches link into them and redirects leak authority; and design one template per page type so product managers can ship a new feature or integration page without a designer.

On a real account: DeepInfra

A new model page has to be indexed within hours of the release or the demand goes to whoever was. Our fix was infrastructure, not writing: crawl budget, internal links from high-traffic pages, sitemap pings on publish, and a page template the catalog fills automatically. Case study

On a real account: ReadMe

For ReadMe.com, we built explicit buying-intent pages for searches like “api documentation tool” and “api documentation generator” — the queries buyers type, kept separate from the developer-facing docs. 74 keywords improved on their old blog versions and total ranking keywords grew 11%, from 550 to 611. Case study

Not sure what’s missing on your site? Run our free GEO audit: it checks whether ChatGPT, Perplexity and Google AI Overviews can find and describe your product, and what to fix first.

Run the free GEO audit

Step 6: Build a content calendar that leaves room for the news

We plan evergreen content a quarter out and thought leadership two weeks out. In dev tools, and in anything touching AI, the news cycle moves in days: a model release, a pricing change, a framework deprecation, a viral benchmark. The pieces that earn the most attention react to that week’s event with a real opinion, and a calendar booked solid three months ahead has no slot for them.

Lane	Planned how far out	What goes in it
Evergreen	A quarter	Build guides, use cases with code, integration pages, glossary. Sourced from the Step 4 backlog; stable demand, no rush.
Launches	Tied to the release schedule	Release write-ups and the launch pages from Step 9. The engineering roadmap sets the dates, not marketing.
Reactive	Held open, filled weekly	Opinion pieces, benchmarks and comparisons on whatever happened this week. One or two slots a month that stay empty until the news fills them.

Run a short weekly editorial call with your authors in the room (Step 2). Review what changed in the category that week, decide whether any of it deserves a reactive piece, and assign it to the author who already has a view. A reactive piece published within 48 hours of the event gets cited in the threads and AI answers that form around it; the same piece two weeks later is a recap.

Who owns what

The calendar only holds if every role knows which part is theirs. For a typical first marketing team at a dev-tools company (a marketing leader, one author, a generalist marketer, a DevRel, and the PMs who already exist):

Role	Owns	Does not own
Marketing leader	Positioning, the calendar, the launch checklist, what gets measured	Writing the technical pieces
Developer-author	Expert pieces; the golden pages and templates for the AI pipelines; review of templated output	Distribution, reporting, product truth
Product managers	The inputs to each pipeline: feature sets, limits, snippets, competitor facts, what is true today	The template, the voice, publishing
DevRel	Engineering access for the author (interviews, sandbox, code review of samples); taking finished pieces to talks, community and the Discord; the Reddit persona accounts	Writing the long-form pieces themselves
Generalist marketer	Distribution of every piece across the five channels (Step 9), the linkbuilding sprints, the dashboard	Technical content, Reddit posting

The point of the split is that the author writes and the new hires carry. A DevRel who spends their week drafting tutorials is a writer with a worse title; a DevRel who spends it on stage with the author’s benchmark in their deck is a multiplier.

Step 7: 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. Nothing else on this list 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.

Got accounts banned	Stayed up and earned upvotes
A helpful comment that steered to the client’s product	A complete answer that names the client and the alternatives
A comparison post that ranked the client first	A benchmark with a method and a result; the client is one of five rows (original data, Step 4)
A “has anyone tried X?” thread with a planted answer	A build guide where the client is one tool in a working stack

The build guides worked best for us. 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 with a small number of persona accounts with real posting history and one rule: no account ever posts something an engineer at your company would not sign.

On a real account: DeepInfra on Reddit

We mapped 42 subreddits and ran a handful of persona accounts with real history, with continuous thread monitoring. 300K+ impressions and 411 brand mentions in communities where Together AI, Replicate and Groq were the default answer, with zero callouts or flags. Case study

Step 8: Set up analytics before the first article ships

We set this up in the first month, before content exists, so every piece has a baseline. If you are being asked for pipeline, this is how you show it.

Web analytics

We run everything on GA4 through Google Tag Manager, reported in Looker Studio. Track a small set of conversion events and nothing else until these are reliable:

Conversion point	What it tells you
Pricing page visit	Buyer intent; the first signal content is reaching the right person
API key created or SDK downloaded	Activation; the number that correlates with revenue for most dev tools
Free trial or self-serve signup	The main conversion
Contact or demo form	Enterprise pipeline
Docs engagement from organic	Whether content pulls developers into the product, not just the blog

Connect these to the landing page and the organic source so you can answer “which articles produce signups” in one chart. That chart is what you show the CEO. It is also the chart that catches the case where sign-ups outrun traffic: on DeepInfra, organic sign-ups per session went from 2.9% to 8.6% in a year while clicks rose 88%, because the new pages land developers who are about to try the product.

Make the conversion a free trial

Developers expect to try before they talk to anyone. Free tokens, a free week, a generous free tier, a sandbox; the form matters less than the fact that a developer can run a request in five minutes. If your only CTA is “book a demo”, content will produce traffic and no pipeline, and you will blame the content.

AI analytics

Set up prompt tracking with a tool like PromptWatch on day one: the questions buyers ask ChatGPT, Perplexity and Google AI Mode in your category, whether you appear, who gets cited instead, and your share of voice against named competitors. The baseline is usually zero, which is the point of measuring it early. Track referral sessions from the assistants in GA4 as well; they are small but growing fast (DeepInfra’s Gemini sessions went from 135 to 1,744 in a year).

On real accounts

The same stack runs on every account; only the activation event changes (API activations for DeepInfra, SDK trials and demo requests for Microblink, parse jobs for LlamaIndex). fraud.net’s prompt tracking benchmarks share of voice against Sift, Forter, Riskified and Signifyd: 5.6% and 1,230+ citations by April 2026, from zero.

Step 9: Turn launches into a repeatable playbook

Dev tools ship constantly, and each release is a demand spike you either catch or miss. A launch is not a blog post on release day; it is a checklist that starts a week before and ends with the new page linked from everything that already ranks.

When	What
A week before	Keyword research on what people will search once it ships: model and feature names, “[competitor] alternative”, migration queries. Pick the primary term for the page title and URL.
The days before	Templated pages from Step 3 drafted; an author (Step 2) writes the release piece with benchmarks and a code sample; comparison and “best of” pages updated to include the new thing.
Launch day	Publish, submit the URL in Search Console, post where your buyers are, and stay in the thread to answer questions.
The first two days	Internal links from your highest-traffic pages and the docs to the new page. The highest-leverage step, and the one most teams skip.
The first two weeks	Outreach to the roundups and comparison articles that already rank for the category, asking to be added.
Day 30	Impressions and clicks on the primary term, sign-ups attributed to the launch pages, AI citations for the new entity (Step 8).

Write the checklist once, assign an owner per row, and run it on every release. The marketing leader’s job is to run it, not to do every step.

Every piece ships everywhere developers are

An article on its own is one URL waiting to be found. The same piece, posted in several forms in the same week, gets found, discussed and cited, and each form feeds the others: the Reddit thread links the article, the LinkedIn and X posts send the author’s network to both, the talk puts it in front of a room, and AI assistants that see the same finding described in five places treat it as established. This is the generalist marketer’s job (Step 6); the author writes it once.

Channel	Form	Who posts	What changes
Your site	The full article: benchmark, build guide or opinion, with the code	The author, under their name	Publishes first, so there is a stable URL to cite
Reddit	A build guide or a data finding in the subreddit where the question lives, with your product as one tool in the stack	A persona account with real history, or the author’s own	Rewritten for the thread, not pasted; answers the question that is actually being asked there
LinkedIn	One specific takeaway in the author’s or founder’s voice, 150 words, the chart or snippet inline	The author, the founder, the engineer who built it	Personal accounts, never the company page; the link goes in the first comment
X	A short thread: the finding, the chart, the code, the link last	The engineer or founder; developers follow people, not brands	Launch day for releases; the same day as the article for everything else
Events	The article is the talk’s outline; the demo repo serves both; the talk is the article’s distribution	DevRel or the engineer	Recorded talk gets posted back to the article; the article gets the slides
Hacker News	Only benchmarks and original data, submitted plainly, with the author in the comments	The author	Never launches or opinion pieces; one callout there costs more than it earns

Run this on every expert piece and every launch. The article makes it citable, Reddit makes it discussed, LinkedIn and X make it seen by the people who buy, the talk makes it remembered. One brief, five posts, same week.

On a real account: DeepInfra

Every model release fills the same three slots from one brief: “[Model] pricing guide” (per-token cost against other providers, context, throughput), “Best API provider for [model]” (an honest comparison with DeepInfra as one entry), and “[Model] integration guide” (endpoint, working sample, common errors). Blog clicks from Google went from 1,347 to 18,551 year over year, sign-ups from organic sessions landing on the blog from 9 to 464, and 10 of the 12 DeepInfra pages Gemini cites most are model-release posts. Case study

The playbook on six accounts

We’ve run every step above on a live account. The pattern across all of them: foundation and measurement first, expert authors on the opinionated content, automation on the long tail, community and linkbuilding feeding the sources LLMs cite.

Convex

Open-source TypeScript backend, a Firebase/Supabase alternative

TypeScript help center (built from no content infrastructure)

Expert author sourcing, intent-clustered keyword map, LLM-format pages, GA4 to signups and activations.

Read the Convex case study

DeepInfra: content

Serverless AI inference, 100+ models, OpenAI-compatible API

Per-release launch engine (pages discoverable within hours of a model drop)

Crawl infrastructure rebuild, ML-infra authors, automated model pages, timed linkbuilding sprints.

Read the DeepInfra case study

DeepInfra: Reddit

Community authority in the subreddits where inference buyers decide

411+ mentions (300K+ impressions · 42 subreddits · zero flags)

Subreddit mapping, multi-persona architecture, top-comment placements on ranking threads.

Read the Reddit case study

Microblink

Identity verification SDKs, 65M+ monthly verifications

+173% traffic (+87% keywords · $33,000/month organic value)

Intent-split architecture, three content formats, glossary and listicles for LLMs, SDK-trial tracking.

Read the Microblink case study

LlamaIndex

Document parsing and agent framework for developers

18x OCR clicks (1,097 sign-ups from new content sections in Q3 · #1 cited domain in AI Overviews)

Low-volume cluster build-out, /insights listicles structured for citations, glossary, sign-up and parse-job tracking.

Ask us about the LlamaIndex work

fraud.net

Enterprise fraud detection platform

1,230+ AI citations (400+ pieces in 6 months · +85% ranking keywords)

Redesign protection, three AI content pipelines with human review, AI share-of-voice reporting.

Read the fraud.net case study

Run it yourself, or run it with us

Everything above is doable by one strong marketing leader. The constraint is time: the nine steps are nine jobs, and the slow ones (finding authors, building page templates, the first Reddit months) are slow because they are trial and error. We have already made most of those mistakes on other dev-tools accounts.

	In-house	With AUQ
Expert authors	You source, trial and manage them	We bring authors we have already worked with in your stack
Pages and templates	Your designer and engineers	Designed and built by our team
Templates and Reddit	Your writer builds the templates, a PM feeds them, someone runs the accounts	Pipelines we have already built on five accounts, adapted to your product; our Reddit team, with your review
Analytics	Set up from scratch	The GA4, Looker and PromptWatch stack from our other accounts

Either way, the positioning and the opinions stay yours.

Start with a 30-minute audit of what you have now

We work with developer-tools, fintech and martech companies where generalist content fails, and we hire a subject-matter author for every account rather than a generalist. Bring your site; we’ll tell you which of the nine steps are missing and what order to fix them in.

See our GEO for PLG SaaS program.

Book an audit with AUQ · Run the free GEO audit · More case studies