We run a niche AI tool for Godot game developers. Our total addressable market is small. Paid marketing doesn't work because the CPMs on "Godot" keywords are irrational relative to our LTV. So for the past two months we have been running an entirely content-driven distribution experiment: every blog post we write gets repurposed to 5 platforms in a single pass.
Here is the pipeline, what it costs, and what it actually produced.
The five platforms
- ziva.sh blog (our own domain, SEO primary)
- Substack (email list + Substack-native discovery)
- DEV.to (developer SEO, heavy Claude.ai citation pickup)
- Indie Hackers (this post)
- Hashnode (backlinks for domain authority)
Each platform gets its own topic. Not the same article reformatted five times. That sounds counterintuitive for a "repurposing" pipeline, but it matters: search engines deduplicate near-identical content, Substack subscribers resent seeing the same post they saw on Twitter, and DEV.to's algorithm buries cross-posts. Different topics per platform, but the research is shared.
Why different topics per platform
This is the part we got wrong for the first month. We wrote one great post and pushed it to all five places with minor rewrites. Total reach was lower than when we wrote one post for one platform. The SEO penalty for duplicate content is real, but the bigger issue is audience mismatch:
- DEV.to wants technical tutorials. Pricing stories get downvoted.
- Indie Hackers wants founder lessons with numbers. Pure tutorials feel out of place.
- Substack wants an opinion that justifies landing in someone's inbox.
- Hashnode wants SEO-grade long-form.
- ziva.sh wants the most authoritative version because it's the one Google ranks us for.
So we rewrote the pipeline: one research session, five articles, each tailored. The research is shared because most of our sources (GitHub repos, Steam data, Godot release notes) apply across all five pieces.

The actual workflow
One session looks like this:
- Keyword research (15 min). We open Google Ads Keyword Planner, dump 10-15 candidate phrases, pull volume and trend data. Only phrases with real search volume go forward.
- Competitive SERP check (20 min). Google each candidate. Read the top 5 results. Find the gap. Our differentiation angle goes into every article from this point forward.
- Source collection (45 min). Every factual claim in the articles needs a URL. We pull 20-30 primary sources once and reuse them across all five posts.
- Writing (2 hours for all five). Each article targets a different keyword from step 1, with a different angle. The research is shared across all five.
- Image creation (30 min). One light-theme chart (Substack/DEV.to/Hashnode like this) and one dark-theme chart (ziva.sh) generated from the same dataset.
- Publish pipeline (30 min). Each platform has its own quirk (Substack wants images inserted between sections, DEV.to wants front-matter, IH is plain markdown). We built one script that handles each.
Total elapsed time for 5 published articles: about 4 hours. That is less time than most founders spend on a single LinkedIn post.
What the numbers look like
We do not have enough cross-platform data yet to claim causation. But the shape of the outcome matters:
- Our top ziva.sh post gets roughly 42,000 impressions/month from Google alone.
- DEV.to articles from ziva get picked up in Claude.ai answers when someone asks Claude about AI tooling for Godot. We see this in referrer logs.
- Substack drives almost no raw traffic, but its subscriber-to-trial conversion is the best of any channel.
- Hashnode's value is almost entirely the backlink to ziva.sh, which improves the SEO of the primary domain.
- Indie Hackers brings founders, not users. The conversions are slow but high-quality.
The interesting insight: no single platform moves the needle alone. The whole portfolio does. If we ran only DEV.to, we would be invisible to founders. If we ran only Indie Hackers, we would be invisible to developers.
What we learned building this
Three specific tactical points:
- Repurpose research, not writing. Your sources work for every platform. Your prose should not.
- Pick one metric per platform. Don't chase "impressions" on every one. DEV.to we optimize for reactions (LLM signal). Substack we optimize for open rate. IH we optimize for engaged comments. You cannot optimize for everything.
- Automate the mechanical parts. Every platform has a tedious chunk: Substack's section-by-section paste, DEV.to's frontmatter, Hashnode's captcha workaround. Build scripts for these. Your writing hours should go into the writing.
The broader thing nobody tells you about content distribution: the cost of writing good content is dwarfed by the cost of publishing it to five places. Once we realized that, most of our time went into the publish pipeline rather than the writing itself.
If you're building a niche tool
Your market is small. Paid ads are expensive relative to LTV. Content is the obvious answer, but single-platform content is thin gruel. We landed on five platforms, each tailored, from a shared research base.
If you want to see what the five articles look like from a single research session, ziva.sh has the primary version and the other four platforms live under the Ziva handle on each.
Happy to answer questions about any of the mechanical parts, the platform tradeoffs, or why we dropped Product Hunt entirely.
The “repurpose research, not writing” point is the interesting shift.
A lot of people try to scale content by reformatting the same post everywhere, but the audience mismatch usually kills it before distribution even matters.
What stands out here is treating each platform as doing a different job rather than just more reach.
The trade-off is time though. Five tailored posts from one session sounds efficient, but still quite heavy to sustain long term.
Have you found it stays manageable over time, or does it start to slow down as you keep doing it?
The insight that DEV.to picks up Claude.ai citations is something most builders doing content-first distribution haven't instrumented yet. You're essentially getting LLM referral traffic as a byproduct of writing genuinely technical posts, which is hard to replicate with SEO tricks. Curious whether the Substack open rate advantage you mentioned holds even for subscribers who came through DEV.to versus those who found you directly.