POST /api/outrank/webhook
, bearer token, schema validated, revalidateTag()
on write.robots.ts
. GPTBot, Claude-Web, PerplexityBot.Applighter has published 118 blog posts, ranks for hundreds of long-tail queries, and does not employ a single content writer.
This is not a growth-hack post. It's what SEO for developer tools actually looks like when you're a two-person team selling React Native templates and the marketing budget is whatever is left after Stripe fees.
Every "SEO for SaaS" guide assumes a content team, or at minimum a fractional writer at $500 a post. Selling templates at $99–$299, that math never worked. At 4 posts a month we'd need to sell one extra license per week just to break even on writers. That's before agency margins, before editorial overhead, and before the reality that most freelance writers cannot tell the difference between EAS Build and expo prebuild
.
The alternative most indie teams pick is "no blog," and then they lose to competitors who show up when a developer searches "supabase vs firebase for react native."
So we rebuilt the operation around what we already had: engineers, a Next.js app, a Supabase database, and a Claude subscription.
| Function a content team does | What we replaced it with |
|---|---|
| Editorial calendar | A markdown queue in scripts/blog-automation/blog-tracker.md |
| Writer drafting a post | Claude Code invoked with a /write-blog skill, --max-turns 25 |
| Editor reviewing tone/facts | House-style prompt with hard constraints plus a grep pass |
| CMS entry | A POST /api/outrank/webhook call with a bearer token |
| SEO metadata handoff | |
generateMetadata() in app/blog/[slug]/page.tsx reads from Supabase |
|
| Cross-posting | A Slack thread that pings a human to paste the pre-adapted version |
| Analytics reporting | Supabase view-count RPC plus a nightly query |
Nothing here is unusual on its own. What made it work was treating the pipeline like an internal API instead of a workflow. The endpoint is versioned. The tracker is in git. The skill prompt is code-reviewed. A blog post is a POST
request, not a Notion doc that gets forgotten.
No CMS. No admin panel. The single write path is POST /api/outrank/webhook
, defined in app/api/outrank/webhook/route.ts
, guarded by a bearer token, processed by modules/services/OutrankArticleService.ts
.
The service extracts author tags from the payload, dedupes by slug, and inserts into blog_posts
. Immediately after the insert it calls:
revalidateTag("blog-posts", { expire: 0 });
So Next.js drops the cached list within seconds instead of waiting out the TTL.
Publishing looks like this from anywhere:
curl -X POST https://yoursite.com/api/outrank/webhook \
-H "Authorization: Bearer $PUBLISH_TOKEN" \
-H "Content-Type: application/json" \
-d @post.json
Three downstream benefits no CMS gives you:
curl
from your laptop, a Zapier flow, a colleague's script. No proprietary editor to learn.A WordPress instance, a Ghost blog, a Contentful workspace: each is a second system to maintain, another set of credentials to leak, and a UI you have to teach a future collaborator. For a small studio the CMS is a liability, not an asset.
The most useful reframing we did was sorting every step into two buckets: mechanical (rules-based, reproducible) and judgmental (needs taste, opinion, or product context).
Mechanical, fully automated:
/public/
paths)components/json-ld.tsx
(BlogPosting, FAQPage, VideoObject auto-extracted from embedded videos)app/sitemap.ts
Judgmental, human-in-the-loop:
The mechanical bucket runs on a cron. The judgmental bucket happens over coffee.
If you're an engineer this split is intuitive. It's how you'd design any pipeline where humans and machines share work. The mistake most content ops teams make is putting humans on the mechanical work (proofreading for length) and machines on the judgmental work (auto-generating topics from keyword volume). Reverse it.
An AI-written post that references real file paths from your codebase reads dramatically differently from a generic AI-written post.
The former sounds like it was written by someone who ships. The latter sounds like a content mill. Same model, same length, completely different reception.
We enforce this by giving the /write-blog
skill a research step that reads the actual repo before drafting. When a post claims "the OutrankArticleService dedupes by slug," it's because a subagent read modules/services/OutrankArticleService.ts
and confirmed it.
The house-style prompt has one hard rule: no "unlock the power of," no "in today's fast-paced world," no "game-changing solution." Not because those phrases are unprofessional, but because the audience is developers and developers spot LLM fluff instantly. If your first paragraph reads like a press release, the tab closes.
For a dev-tools company the internal link graph matters more than external backlinks, because the point of ranking for "React Native boilerplate" is routing that reader to a product page.
Our rule: every post links to at least one template with UTM parameters, and anchor text varies per post so the pattern doesn't look manipulative. lib/blog-tags.ts
maps every slug to topical tags, and getRelatedSlugs()
surfaces three related posts at the bottom of each article.
What's less common is treating the template catalog as a first-class node in that graph, not a destination sitting outside it. A post about Supabase auth links to the specific template that ships with that exact auth setup. Anchor text, product, and article all agree.
Our top-converting page is a blog post about push notifications, not the homepage.
Open app/robots.ts
and you'll find something that would have made a 2022 SEO agency nervous: we explicitly allow GPTBot, ChatGPT-User, Claude-Web, PerplexityBot, and Applebot-Extended. We block admin routes and auth callbacks. AI crawlers are welcome.
The reasoning is boring math. When a developer asks ChatGPT or Claude for "best React Native template with Supabase auth," the answer comes from whatever the model has indexed. Being excluded from that retrieval set costs you a whole channel.
Concretely it changes what we write:
No keyword-first planning. Picking a topic because it has 10,000 monthly searches is how you publish "What is TypeScript?" for the 400th time. We start with a real thing our templates do, then find the keyword that describes it.
No translated backfill. Localizing 100 posts to 8 languages produces 800 pages of mostly-noise and wrecks your crawl budget.
No featured-snippet chasing on non-transactional queries. A snippet for "what is a React component" is worth nothing when that reader isn't buying anything.
No off-the-shelf content generation tools. We evaluated several. They produce content that ranks briefly then dies, because it has no anchor into a real product. Our pipeline works because it's coupled to our repo, not because it uses a fancier model.
In the order we'd do it if starting over:
/api/webhook
publishing endpoint.The AI pipeline sounds too good. Here's the part the case studies leave out: the first three months of building it cost more than three months of hiring a writer would have.
We paid the setup cost because we were building once and running for years. If you're validating a product idea over the next 90 days, hire a writer. If you plan to still be publishing in three years, build the pipeline.
What's your setup? If you're running content for a dev-tools company, drop your volume and stack in the comments. I'm most curious whether anyone has shrunk the judgmental bucket without the output going generic. That's the ceiling we keep hitting.