Building a Content Brief Tool in Public

We’ve been quietly shipping Ranklet for a while now, and the other nine posts on this blog earn the right for this one to exist. Founder voice, no marketing language, no “lessons learned” listicle structure. What we set out to build, what turned out to be harder than we thought, what surprised us once people started using it, and where we are now.

If you’re building something similar, some of this might save you a quarter. If you’re a user or a potential user, it’s the most honest account we can give of why this tool exists in the shape it does.

What we set out to build (and what we thought would be hard)

The original problem was personal. Writing content briefs by hand is a 60–90 minute job per piece if you’re doing it properly: reading the live SERP, capturing PAA, calibrating word count, naming the differentiation angle. At three pieces a week, that’s six hours of brief work, which is its own part-time job.

We figured we could compress it into something closer to 30 seconds with the right combination of live SERP data and structured AI synthesis. That’s the whole thesis. Nothing more clever than that.

What we thought would be hard: the SERP data freshness problem. Getting the live top 10 reliably, at scale, without fighting an arms race against Google’s anti-bot defences. We spent the first month worrying about this almost exclusively.

What turned out to be hard: not that.

The SERP data problem: freshness, reliability, and no scraping

The SERP problem solved itself within three weeks. We use a vendor (DataForSEO) that handles the fetch reliably with proper rate limits and proper data quality. The data isn’t scraped from Google; it’s pulled through the same infrastructure that runs enterprise SEO platforms. We pay per call, the prices are reasonable at our scale, and the freshness is genuinely live at the moment of generation.

The lesson, which we should have started with: SERP data is a solved problem at the infrastructure layer. We were planning to build something that doesn’t need building. The right question wasn’t “how do we get the data”; it was “what do we do with it once we have it.”

(For users: this is also why your brief reflects what’s currently ranking, not last week’s snapshot. The cost we pay per brief is partly the live SERP fetch. It’s why we’re not interested in a model that runs everything off a cached dataset. The data is the substance. Why live SERP data is the core of every brief we generate is the longer version of the same argument.)

Making the AI output consistent when the input is a free-form keyword

This was the actual hard problem.

A user gives us a keyword. Could be five characters or fifty. Could be a long-tail question or a head term. Could be in English, could be in some weird mixed-script form we hadn’t anticipated. The output has to be the same 12-section brief every time, with the same field names, the same depth, the same structure. The writer downstream is depending on consistency.

The naive approach (“ask an LLM to produce a brief”) gives you wildly variable output. Different keyword shapes produce different brief shapes. Section names drift. Some briefs get long outlines, some get short ones, some skip fields entirely. The model has its own opinions about what a brief should look like and they aren’t yours.

What worked: building the brief generator as a structured pipeline that pulls the SERP data, runs a series of model calls each with a tightly scoped job, and assembles the results into a fixed schema. The model isn’t writing the brief; it’s writing specific fields with specific constraints, and the assembly is deterministic. Same output shape every time. Different content because the input data is different, same structure because the schema is fixed.

That took most of the first three months to get right. It’s still where most of the engineering attention goes.

The 12-section brief format: how we decided what goes in

We didn’t invent the 12-section format. We arrived at it by writing briefs by hand across maybe 80 keywords over a few months and noticing that the briefs that produced ranking content all carried the same set of fields. Briefs missing any of those fields produced articles that fell short in a predictable way.

The fields are: search intent, content type, word count range, target audience, tone and voice, differentiation angle, three title suggestions, meta description, featured snippet target, full outline with per-section guidance, E-E-A-T signals, and a keyword and PAA-questions block.

We dropped fields that sounded good and didn’t earn their place. “Competitor links”: too easy to misuse, encourages copying. “Internal link suggestions”: too dependent on the user’s site for us to do well at this stage. “SEO score”: a number that means nothing and everyone optimises for. The 12 we kept all carry their weight on the writing side.

The format isn’t sacred. We’ve revisited it twice and may again. The constraint we hold is: every field has to be something a writer would actually use, not something that exists because it makes the brief look more thorough.

What surprised us: how writers actually use a brief

The biggest surprise from launching: people don’t use the brief the way we expected.

We thought of the brief as a strategic document the writer reads, internalises, then writes from. That’s how most of the documentation on briefs treats them. In practice, a large fraction of users treat the brief as the article outline itself. They paste it into their CMS, expand the H2s with paragraphs of writing, and ship.

That changed how we think about the brief structure. If the brief is functioning as a writing-time scaffold and not just a pre-writing document, the per-section guidance has to be precise enough to write directly into. “H2: What is X, definitional, 80 words, no preamble” works for both readings: the pre-writer absorbs it as a strategic note, the in-line user expands it directly into prose.

So we tightened the per-section guidance. The briefs are now written for both use cases. That wasn’t planned; it came from watching users.

The ChatGPT question: an honest answer

Every demo, every signup conversation, the same question comes up: “why is this different from asking ChatGPT for a content brief?”

The honest answer is short. ChatGPT writes from its training data. Ranklet pulls live SERPs at generation time. That’s the engineering constraint that shaped every other product decision.

The longer version: ChatGPT can write a competent-looking brief. It can name sections, suggest H2s, draft a meta description. But it doesn’t know what’s currently ranking for your keyword. It can’t tell you the median word count of the live top 10 because the live top 10 isn’t in its context. It can’t surface the current PAA cluster because PAA changes monthly and the model’s training is fixed. Everything strategic in a brief depends on the live SERP, and the live SERP is exactly what a pure-model approach doesn’t have.

That’s not a knock on the model. It’s a question of architecture. Our brief tool is a SERP-fetcher with a structured AI synthesiser bolted on. ChatGPT is a generalist assistant with broad capability and no live web fetch at brief generation time. Different tools, different jobs.

If you’re an early stage user weighing whether the tool is worth the price over a manual prompt, the fair test is: generate a brief in our tool, generate a brief with a manual prompt from your favourite LLM, then check the live SERP yourself. The deltas tell you whether the live data is doing work for you or not.

What’s still broken and what we’re fixing next

The brief generation is solid. The product surface around it isn’t, yet. Here’s what’s actually shipping in the next few months.

SERP location selector. Right now we default to United States SERPs. For users outside the US (and there are more of you than we expected) the wrong geographic SERP is the wrong SERP. Adding a country selector to the brief generation form is the most-requested feature we have. It’s mid-implementation.

Stripe billing. Currently we run on a quieter payment surface that’s enough for early users but not for serious team usage. The full Stripe integration with overage packs, annual billing, and subscription self-service is in progress.

PDF export and cleaner clipboard copy. The Markdown copy works. The PDF export is partially built but not shipped. Some users want it; some don’t care. We’re finishing the partial implementation.

Email confirmation and disposable-email blocking. Operational hygiene. Necessary; not glamorous.

We don’t promise dates because we miss them. The work happens in the order that the user signal supports.

Where Ranklet is now: pricing, user count, what we’ve learned

Pricing is three tiers: Free (3 briefs per month, no credit card), Starter ($29/month or $23/month annual, 20 briefs), Pro ($79/month or $63/month annual, 100 briefs). Overage packs are $9 per 10 briefs on any paid plan. No contracts, cancel any time from the billing page. See how we’ve structured the pricing.

The shape is deliberate. The Free tier is the trial: three briefs is enough to evaluate the tool honestly. Starter is for solo writers and freelancers. Pro is for agencies and content teams. No enterprise tier yet because we don’t have the seat management, audit logging, or SSO infrastructure that an enterprise tier honestly requires, and we’d rather not advertise something we don’t yet deliver.

What we’ve learned that wasn’t obvious going in:

• The hardest engineering problem is not the data; it’s the consistency of structured output.
• Users want fewer features done better, not more features done worse.
• A direct refund-on-failure policy buys more trust than any marketing copy.
• “Live SERP data” sounds technical and is actually the most user-visible part of the product. Briefs that reflect current rankings feel different from briefs that don’t.

If you’re a writer or a content manager and the brief stage is the bottleneck for you, try Ranklet, 3 free briefs, no credit card. If you’re building something similar: ignore the SERP problem early, focus on the output consistency problem, and watch how users actually use the thing once it ships. That sequence saved us a quarter the second time we caught ourselves doing the opposite.