Content marketing for a small team: the first 90 days

Content marketing for a developer audience takes five things in the first 90 days:

a written positioning page,

one developer-author who can write for engineers and technical buyers,

a conversion event in analytics,

a calendar with a slot held open for the news, and a backlog ordered by distance to conversion. One writer plus templates carries the volume.

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

I love this industry, professionally and personally, and I think it is 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.

Each step builds on the step before. At the end of it your marketing team should be able to get a variety of content ideas, content workflows and high-quality output from materials you already have.

Key takeaways

• One author, four multipliers: one developer-author at $250 to $800 an article, two expert pieces a month, plus templates that produce dozens of pages at the cost of a PM’s inputs.
• Count conversions in week one: custom GA4 events before anyone touches a page, so every later decision has a baseline.
• Positioning is one page, written down: the same sentence on the homepage, the docs, the README and the founder’s LinkedIn headline, word for word.
• Order the backlog by distance to conversion: quickstarts first, then comparison and migration pages, then benchmarks, then use cases.
• Leave one or two calendar slots empty: in dev tools the news cycle moves in days, and a reactive piece published within 48 hours gets cited in the threads that form around the event.
• Analytics ships before the first article: four conversion events, one dashboard, and prompt tracking whose baseline is usually zero.

One writer, a team’s worth of content

The model is one developer-author whose hours go only where judgment is required, and four things around them that multiply every hour.

Everything in this article is one of those four multipliers or the measurement that proves they work.

The author’s time is the scarce input. Each multiplier turns one of their hours into something that would otherwise take a hire: the template replaces a junior writer, the interview replaces an SME, the channels replace a social manager, and DevRel and marketing replace a distribution team.

The plan that follows:

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

Count conversions from the start

Everything else here 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, then set this up in the first week, before anyone touches a page, so every later decision has a baseline.

Custom events capture it. The default GA4 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 stack that carries them is later in this article.

The setup is small and should stay small until these are reliable:

Event	What it tells you
Conversion (signup, API key, SDK install or download), with landing page and source	Which page or post brought it
First API call or key created	Whether the conversion turned into use; the number closest to revenue
Pricing page visit, with the referring page	Which content produces buying intent
Click from docs into the product, or “copy” on a code block	Whether the docs are a route to the product or a dead end
Partial form fill	Readers who meant to convert and stopped; which field, on which page
Deep scroll (75% of a long page)	Interest on pages that have no next step yet
Contact or demo form	Enterprise pipeline, for the accounts that do not self-serve
“How did you hear about us?”	Reddit threads, a colleague, a podcast, an AI answer; the sources trackers miss

That last row is there because neither source of truth is complete on its own. Many developers block trackers, and visits from ChatGPT or Perplexity often arrive as direct traffic, so the free-text question catches what GA4 cannot.

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.

Report it monthly, by page, to the whole team. The same report tells you which posts to keep, which pages lead nowhere, and, later, when the company is ready to hire a marketing leader.

On a real account: LlamaIndex. Two events were enough 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, was decided from that report rather than from traffic.

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.

It comes first because everything downstream repeats it: every page, article, Reddit comment and launch post, and the trial brief you hand an author in the next section.

With no marketing leader, each person who writes explains it their own way, and the site, the docs, the README and the founders’ talks each describe a slightly different product.

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.

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 the report above. 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].”

Then write three artifacts before any content ships:

1. A one-sentence category statement in the form above. 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. Organise it around the buyer and the problem they search for. 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 it from 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. Together AI, Replicate and Groq were already in the Reddit recommendations when DeepInfra started, and you cannot become the default in a category while refusing to mention the incumbents.

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.

Positioning is a distribution problem. The sentence is easy to write; the work is putting the identical sentence on every surface a developer or a crawler reads first, so both arrive at the same answer about what you are.

It is finished when someone outside the company can read the homepage and explain the product back in one sentence.

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

We have seen this repeatedly: solutions pages miss obvious features or industries. If it is 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: LlamaIndex. The story had to move from the open-source framework developers knew to the commercial document-parsing product.

The positioning page set the KPI with it: non-branded organic traffic, “best OCR software” over “llamaindex OCR”. Every piece since has been written to that sentence, and clicks on queries containing “ocr” went from 303 to 5,454 in a year.

On a real account: Microblink. Three products, three audiences (developers, compliance officers, enterprise security buyers).

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

Start with one developer-author, in week one

Recruiting starts in week one because the right fit takes time to find, especially among freelancers. For technical content the strongest candidates are working developers who write about their field on the side.

The author worth keeping brings opinions about the category before they learn yours, wants the 30-minute call with the engineer who built the feature, treats the editorial meeting as part of the job, and often runs a tech blog of their own.

Budget $250 to $800 per article depending on depth and how scarce the expertise is, and plan to trial three to five authors for every one you keep. Pay trial tasks at the full article rate.

Where to look, how to get a reply, how to run the paid test, and what each of those signals looks like in practice are in the full guide to hiring technical authors.

What you already have to repurpose

A product-led company reaches its first content hire with more technical material than it thinks: docs and reference pages, a changelog, support threads, internal engineering write-ups, benchmarks, recorded talks and a README.

Listing everything the company has published, and what each item could become, takes a day. It usually ends the argument about what to write next: the answer is already on the site.

What you already have	What else it is
Docs: quickstart, API reference, guides	A quickstart per language or framework your users arrive with
README, examples folder, starter kits	A “build [thing] with [product]” guide per example; a README opening with the positioning sentence
Changelog and release notes	Launch posts for the entries that deserved one and never got it; a quarterly “what changed” round-up
RFCs, design docs, post-mortems	An architecture piece: the trade-off you chose and what you gave up
A benchmark an engineer ran internally	An original-data post with the method published
Recorded talks and video walkthroughs	An article (the talk is its outline), a written tutorial with the code pulled out
Long answers in Discord, Slack or GitHub issues	A docs page for every question answered three times; a glossary entry if it defines a term
Sales and onboarding calls, support tickets	Use-case pages in the buyer’s own words; “[product] vs [alternative]” pages for the comparisons that keep coming up

The last row is the one most teams walk past. Sales calls and tickets are the only sources that tell you what developers struggle with in their own words, with a frequency attached, and counted across a quarter they are an original study nobody else can publish.

One rule makes this work on a team of one or two: 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.

The full method, five pieces from every one, is in the guide to content ideas for product-led SaaS.

What to write first

The backlog starts with the pieces closest to a conversion: quickstarts, then comparison and migration pages, then benchmarks, then use cases.

The positioning page tells you what the story is, the monthly report tells you what is already working, and the inventory above tells you what you can publish without anyone writing from scratch.

This section turns all three into a backlog, orders it, and fixes 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, and a 30-minute pass each week turns it into briefs:

What happened this week	The brief it becomes
A release or changelog entry	Launch post or changelog-plus-post, in the positioning language
A pull request or design doc worth explaining	An architecture piece: the trade-off you chose and what you gave up
A benchmark an engineer ran	An original-data post with the method, and a comparison page if it beats a named alternative
The same question in three tickets or Discord threads	A docs page or quickstart; a glossary entry if it defines a term
A comparison raised on a sales call	A “[product] vs [alternative]” or “migrate from [alternative]” page, in the buyer’s words
A talk accepted or a video recorded	The article it becomes

The order

Order the list by distance to conversion. Writing whatever is most interesting first is how a team ends up with a good essay and no quickstart.

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. Wording stays with the writer.

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.

Five questions get what the interview needs: what they built and what they considered instead, what limitation they wish was documented, and three more that pull out the number, the surprise and the 2am advice. The full set, with the sales equivalents, is in the content ideas guide.

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, outside any one person’s head.

Build a content calendar that leaves room for the news

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 weekly brief list; stable demand, no rush.
Launches	Tied to the release schedule	Release write-ups and the launch pages. The engineering roadmap sets the dates.
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. 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.

Two habits keep the calendar reliable. Track the date you planned a piece against the date it published; if evergreen pieces are consistently late, the calendar is too full.

And when a reactive slot goes unused for a month, that is fine. The slot exists so it is there when the news arrives.

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 every channel your buyers use, 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.

Set up analytics before the first article ships

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. The event detail is in our guide to GA4 for SaaS.

The conversion events from the first section feed it, with one dashboard on top and AI visibility reported next to signups so the two are read together. That is the stack we install on every account.

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.

The playbook on real accounts

Every step above has run 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. A 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.

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.

Final thoughts

The first 90 days are five decisions, and four of them are made before a single article publishes: what counts as a conversion, what the one sentence about the product is, who writes, and what order the backlog runs in.

The fifth is holding a slot open for the week the category moves.

Teams that skip the measurement get a year of content and an argument about whether it worked. Teams that skip the positioning get a year of content describing four different products.

Developers, CTOs and the compliance or fraud specialists who evaluate alongside them read for the caveats, which is why the author’s judgment is the one input you cannot template.

I would spend the first two weeks on the analytics and the positioning page, start author outreach the same week, and publish nothing until both exist.

Bring your site and we will tell you which of these pieces are missing and what order to fix them in. Book a 30-minute audit with AUQ.