Turning your existing content into signups and AI mentions

How we did it at LlamaIndex and Convex.

Most developer-tools companies have more content than they think and less of it working than they hope. Docs, a blog, a changelog, a YouTube channel, a Discord full of answered questions, all written by founders, engineers and a DevRel who each explain the product their own way, and none of it tied to a conversion.

I wrote this guide for the stretch before the first marketing hire. I’m not going to ask anyone to write more. I’m going to ask your team to count what is already working, agree on one story, give every existing page a next step, and get more out of each piece you already produce. It is what we run for clients like Convex and LlamaIndex, in the order we run it. Most steps end with what it looked like on one of our live accounts.

Step 1: Count conversions from the start

Everything else in this guide is a judgment about what is working, and nothing is working until a conversion can be traced back to the page that brought it. Your conversion is whatever a developer does that says they are trying the product: a signup for some tools, an API key, an SDK install or a download for others. Pick the one closest to real use. We set this up in the first week, before anyone touches a page, so every later decision has a baseline.

We do it with custom events in GA4, through Google Tag Manager. The default events tell you a page was viewed; custom events tell you what the reader did on it, and almost anything a developer does on a page can be tagged: a click on “copy” in a code block, a visit to pricing, a form started and abandoned, a scroll past the fold of a long tutorial. The setup is small and should stay small until these are reliable:

The interest signals (copy clicks, partial fills, deep scrolls) matter most before the conversion numbers are large enough to read. A tutorial with 400 deep scrolls a month and no next step is a conversion problem you can fix this week; a page with 400 sessions and no scroll is a different problem.

We report it monthly, by page, to the whole team. The same report tells you which posts to keep (Step 3), which pages lead nowhere (Step 7), and, later, when the company is ready to hire (Step 10).

On a real account: LlamaIndex

Two events were enough for us to run the content program: visits to /pricing from an article, and a newsletter-signup event, both already in GA4. Everything that followed, from which clusters to expand to which pages to merge, we decided from that report rather than from traffic.

Step 2: Write the positioning down, once

Positioning is how you explain what the product is, who it is for, and why someone should pick it over what they use today. With no marketing leader, everyone who writes explains it their own way, and the site, the docs, the README and the founders’ talks each describe a slightly different product. In this step we turn that into one page everyone writes from.

We build it from what already exists: how the founders describe the product on sales calls, how the docs introduce it, and the posts that brought in the most conversions in Step 1. It answers five questions:

1. Who is it for? The type of team, and the moment they need it.
2. What would they use instead? A competitor, an open-source tool, or building it themselves. Name them.
3. What does it do that those don’t?
4. What’s the proof? A benchmark, a code sample or a customer result for each claim. A claim without one comes off the page.
5. What’s the one sentence that sums it up? In the form “X is a [category] for [who] that [does what], an alternative to [the two names they already know].”

It is finished when someone outside the company can read the homepage and explain the product back in one sentence. Then the sentence goes on the homepage, the docs landing page, the README and every founder’s LinkedIn headline, word for word; consistency across sources is what makes an AI assistant confident enough to repeat it.

On a real account: LlamaIndex

The story had to move from the open-source framework everyone knew to the commercial document-parsing product. The positioning page we wrote set the KPI with it: non-branded organic traffic, “best OCR software” rather than “llamaindex OCR”. Every piece we’ve written since has been written to that sentence, and clicks on queries containing “ocr” went from 303 to 5,454 in a year.

Step 3: Take stock of what is already published

A list of everything the company has published, and what each item could become. It takes us a day, and in my experience it usually ends an argument about what to write next by showing that the answer is already on the site. An early-stage dev-tools company has more of this than it thinks:

The last two rows are not published content, and they are the most valuable in the table. Sales calls and tickets are the only sources that tell you what developers struggle with in their own words, with a frequency attached. Counted across a quarter they are an original study nobody else can publish: “the 10 things developers get wrong integrating [category], from 400 support tickets” is the kind of piece Reddit upvotes and AI assistants cite, because the data is yours.

What an inventory finds

On a larger account, Microblink, our inventory covered 1,084 live URLs and found 198 groups of pages answering the same question; 350 pages were recommended for merge or redirect. A company before its first marketing hire will have a tenth of that, and the same pattern: a handful of pages doing the work, and a long tail competing with them.

Step 4: Get five pieces from every one

The team already produces more raw material than it publishes: a changelog entry, a conference talk, a long Discord answer, a YouTube walkthrough, a sales call. Each is one piece in one place. The habit we build in this step is to ask, of everything that already exists, what else it is.

The rule I’ve found makes this work without a marketing leader: the person who made the original does not make the derivatives. The engineer gave the talk; the DevRel writes it up; whoever handles the changelog sends the email. Nobody is asked to write more than they already do.

On a real account: Convex

Convex had hours of YouTube content that developers were watching and nobody was reading, because none of it existed as text. We turned the videos into articles on their Stack blog: the transcript as the source, the code written out where the video only showed it, Convex’s voice, and internal links into the docs. The engineers who recorded the videos did nothing new. Case study

Step 5: What to write first

Steps 1 to 4 tell you what you have, what the story is and what each existing piece can become. In this step we turn that into a backlog, order it by distance to conversion, and fix how much engineer time each piece is allowed to cost.

The weekly brief list

A brief is a short note: what to write, who it is for, and what it must show (one claim with a number, one limitation stated plainly, the next step the reader takes). The material is already flowing past you. We do a 30-minute pass each week to turn it into briefs:

The order

We order the list by distance to conversion, not by what is most interesting to write:

1. Quickstarts for any language or framework your users arrive with and you do not cover: the shortest path from nothing to something working.
2. Comparison and migration pages, because they catch developers at the moment they are choosing.
3. Benchmarks, because they are the format developers and AI assistants cite.
4. Then use-case pieces for the features most users do not know the product has: a real problem, a working example. Everything else waits.

The engineer time budget

Fixed and small, per piece: a 25-minute interview where the writer gets the details, and a 20-minute review where the engineer checks facts and code, not wording. Review is where engineer time actually goes, and a team that spends longer fixing drafts than it would have spent writing them has the budget wrong; the brief and the template are what keep the review to 20 minutes. These are the five questions we ask to get what the interview needs:

• What did you build, and what did you consider instead?
• What broke or surprised you along the way?
• What number would you put on a slide about this?
• What would you tell someone integrating this at 2am?
• What limitation do you wish was documented?

Who drafts

The DevRel, if there is one. A freelance developer-author at $250 to $800 a piece if there is not: full-time developers who moonlight as writers, found on dev.to and Medium by your stack’s tags, trialled on a paid piece. Or an agency. Whichever it is, the brief list, the templates and the backlog live somewhere the first marketing hire will inherit, not in one person’s head.

Step 6: How to use AI: who builds the templates, and how

Getting a lot from a little content means never writing the same kind of page from scratch twice. We hand-write the first four of a type; they become the golden pages we extract a template from, and from the fifth on, the template plus the week’s brief produce the draft. AI is the drafting step in that loop and nothing else: it does not pick topics, decide claims or publish.

Which content types get a template

Anything you will write more than four times. For this segment, five types repeat:

Who builds what

Build it in a tool you control. We use AirOps for templated volume and Claude for one-off drafts; whichever AI builder your team already has will do, as long as the template and the inputs go in and a draft comes out with every step visible. The method does not change with the tool: four golden pages written by hand for one specific reader, a template and a review checklist extracted from them, the first four generated pages read in full (fix the template, not the pages), and after that a person reads only the pages that earn impressions, clicks or AI citations.

Two things we keep out. Tools that offer to rewrite your live pages for AI search: they flatten the voice, insert claims nobody checked, and they are the fastest way to publish something an engineer would not sign. And AI on the claims, numbers and code: those come from the engineer’s fields or they do not go in. Analytics tools such as PromptWatch belong in the stack for the opposite reason: they tell you which pages get cited and how AI assistants describe you, which is the input to the next brief, not a replacement for writing it.

On a real account: LlamaIndex

The /insights listicles and /glossary are templates of exactly this kind. Beyond the conversions (Step 7), they are what AI assistants cite: 11 of the 15 most-cited llamaindex.ai pages in AI answers are /insights pages, weekly citations to the domain doubled between May and July, and llamaindex.ai moved from the third most-cited domain in its category, behind YouTube and Reddit, to first in Google AI Overviews, AI Mode and Perplexity.

Step 7: Make the docs and blog the route to conversion

Every post and docs page should give the reader a next step. Most do not; they end, and the developer who was ready to try the product goes back to the search results. In my experience this is the fastest-moving step in the guide, because the pages already have readers.

Three rules of thumb we follow:

• The next step is a code block, not a banner. A quickstart (the shortest path from nothing to something working), an example they can copy, or a link into the product at the exact point in the page where they would want it. Developers skip marketing CTAs and read code.
• Start with the pages that get read most and lead nowhere. The Step 1 report sorts them for you: high sessions, zero conversions or pricing visits. Ten pages usually account for most of the gap.
• The conversion is a free tier or a sandbox. Developers try before they talk to anyone. If the only next step is “book a demo”, the content will produce traffic and no conversions, and the content will get the blame.

We measure it as conversions per 1,000 docs sessions and per 1,000 blog sessions, monthly. The number is small at first and it moves fast once the top ten pages have a next step.

On a real account: LlamaIndex

The /insights and /glossary sections had no traffic a year ago. In Q3 they drove 35,349 Google clicks, 21% of the domain’s total, and sessions landing on them produced 1,097 signups, 2,255 pricing-page views and 450 parse jobs run. Templated pages convert when they land a developer on something they can run.

Not sure which pages are doing the work? Run our free GEO audit: it checks whether ChatGPT, Perplexity and Google AI Overviews can find and describe your product, and which of your pages they cite.

Run the free GEO audit

Step 8: Launches: how each release goes out

A launch is how a new product or feature gets announced so the right people notice it and try it. Without a marketing leader the usual failure is that every release gets the same treatment, which means the big ones are under-announced and the small ones clutter the channels. The first decision is which kind of release this is.

The full-launch kit, each part owned by a named person, with the dates set from the engineering roadmap:

• An announcement post saying what is new, who it is for and how to try it, in the words of the positioning page
• Updated docs and changelog, live before the post
• A short demo, recorded once, embedded in the post and cut for X
• Posts where developers gather (Hacker News, Reddit, the company’s Discord), under the founders’ and engineers’ own names, never persona accounts
• An email to existing users
• Internal links to the new page from the five highest-traffic pages on the site, the same day

On a real account: DeepInfra

DeepInfra releases a new model most weeks, so we turned the launch kit into a template: every release fills the same three slots, a “[model] pricing guide”, a “best API provider for [model]” comparison with DeepInfra as one honest entry, and a “[model] integration guide” with a working sample. Blog clicks from Google went from 1,347 to 18,551 year over year, and signups from organic sessions landing on the blog from 9 to 464. Case study

Step 9: Who writes what

Several authors and no owner is how the positioning drifted in the first place. The split we use gives each person the work they are good at and have time for, and puts one name on the check.

Not yet

Templates with a named reviewer are in (Step 6). Three things from the full playbook are not, because they need an owner this team does not have: pipelines that publish without a reviewer, Reddit persona accounts (they get banned without someone running them daily), and linkbuilding, which is a sustained campaign rather than a task. All three are the first marketing leader’s job. Until then, people post as themselves, the templates carry the volume, and the checker keeps it consistent.

Step 10: When you are ready for a marketing leader

The Step 1 report answers this too. Three signals, any one of which is enough:

• Content-attributed conversions have grown for three months running and the people producing the content cannot keep up with what the report says to do next.
• The inventory backlog (pages to update, merge or write) is larger than the team ships in a quarter.
• Launches are landing (the full-launch kit produces conversions you can see) and there are more of them than one person can run alongside their actual job.

The hire inherits something most first marketing leaders never get: a positioning page the whole company already writes from, an inventory with a decision on every page, attribution that already works, a launch rubric the team already follows, and a monthly report that shows what to keep doing. Their first quarter is the “not yet” list, not the basics.

The playbook on real accounts

The same steps, as we ran them for three companies at different stages.

LlamaIndex

Document parsing and agent framework; moving the story from open source to the commercial product

1,097 signups (from the new content sections in Q3 · OCR clicks 303 → 5,454 in a year)

Positioning to a non-branded KPI, two GA4 events, templated sections built to land developers on something they can run.

Ask us about the LlamaIndex work

Convex

Open-source TypeScript backend

Video to text (YouTube walkthroughs turned into Stack blog articles with the code written out)

The repurposing step in practice: the engineers recorded nothing new, and content developers were watching became content search engines and AI assistants can read.

Read the Convex case study

DeepInfra

Serverless AI inference, a new model most weeks

9 → 464 (signups from organic blog sessions · blog clicks 13.8x year over year)

The launch kit as a three-slot template per model release, run on every release without a marketing leader writing anything.

Read the DeepInfra case study

Run it yourselves, or have us run it until you hire

Everything above is doable by a founder and a DevRel in the gaps between their actual jobs, which is the problem. Here is what I’ve seen each path look like for the first six months.

What stays yours either way: the positioning, the opinions, the relationships in your community.

Start with the inventory

We work with developer-tools companies where generalist content fails, and we hire a subject-matter author for every account rather than a generalist. Send us the site; we will come back with the inventory, the ten pages that lead nowhere, and what we would do first.

See our GEO for PLG SaaS program.

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