Search for a command to run...
Setting up a write-once, publish-everywhere pipeline for a technical blog
No comments yet. Be the first to comment.
This is the first post on this blog — and naturally, it's about how I built the blog itself.
I'm an AI engineer working on LLM/RAG agents and computer vision. I've been building things for a while — research projects, side projects, production systems — but most of that work lived in private repos and slide decks nobody would ever see again. I wanted a place to write — in English, for a global audience — about what I build, why I make certain decisions, and what breaks along the way.
The requirements were simple: a technical blog in English, with a way to reach Korean readers too, without maintaining two completely separate blogs.
Here's how I set it up.
I'll save you the five-platform comparison table. I ruled out self-hosting early — spinning up a Hugo or Jekyll site is fun, but maintaining it is a distraction I don't need right now. Medium I kept, but for essays, not technical writing (more on that later).
The actual decision came down to dev.to vs Hashnode.
Both are free, markdown-based, and have built-in developer communities. Both have good SEO. On the surface, they look almost interchangeable. But one thing tipped the scale:
Hashnode lets you own your canonical URL.
With Hashnode, I mapped my custom domain (blog.yunasim.dev) and every post lives there. When I cross-post to dev.to, the canonical URL points back to my domain, not Hashnode's. That means Google indexes my site as the original source, and all the SEO juice flows back to me.
On dev.to, your posts live on dev.to/yourusername. You can set a canonical URL pointing elsewhere, but the platform is designed around their domain. If I'd gone with dev.to as my primary, I'd be building on rented land.
| Hashnode | dev.to | |
|---|---|---|
| Custom domain | ✅ Free, full ownership | ❌ Posts live on dev.to |
| Canonical URL | Your domain by default | Manual, points to external |
| SEO ownership | Your domain by default | dev.to domain by default |
| Community | Smaller, growing | Large, very active |
| Cross-posting | Built-in import | Built-in canonical URL field |
The trade-off is community size — dev.to has a bigger, more active feed. But that's exactly why I use both: Hashnode as home, dev.to as distribution.
Here's the part I actually want to talk about.
Most developers either blog on one platform and call it a day, or try to maintain multiple blogs and burn out in a week. I wanted a middle ground: write once, distribute strategically.
The key insight was separating my content into two tracks:
Not everything I write belongs in the same place. A deep dive into how I built a RAG pipeline is a fundamentally different piece of content from an essay about why self-help advice rarely reaches who it should.
Tech track (code, architecture, project retrospectives):
Hashnode (blog.yunasim.dev) → English original, canonical source
dev.to → English cross-post, canonical URL points back to Hashnode
I also translate select posts to Korean on velog, but that's a separate workflow — the core pipeline is English-first.
Essay track (ideas, perspectives, takes):
Substack (yunaisme.substack.com) → English original
Medium → Abridged/teaser version, funnels readers to Substack
LinkedIn sits in the middle as a hub — 2-3 lines of insight from either track, with the full link dropped in the first comment.
A few reasons:
Different audiences. The person reading a technical walkthrough of my VLM document parsing pipeline is not the same person reading my thoughts on the frame card method for structuring essays. Mixing both on one platform dilutes the signal for both audiences.
Different formats. Tech posts need code blocks, diagrams, and headers. Essays need breathing room and flow. Hashnode is optimized for the former; Substack for the latter.
Different discovery channels. Tech posts get discovered through dev.to feeds, Google searches, and Hashnode's community. Essays travel through newsletter subscriptions and social sharing. Separate tracks let each piece find its natural audience.
Here's what happens when I finish a tech post:
The whole thing takes maybe 20 extra minutes per post beyond the initial writing.
When the same content exists on multiple URLs, search engines need to know which one is the "real" one. My setup ensures every cross-posted article's canonical URL points back to blog.yunasim.dev — so dev.to and Medium serve as distribution channels, but Google credits my domain. It's a small technical detail that compounds over time.
This pipeline is running, but there's more I want to set up:
RSS automation — right now the dev.to cross-post is manual. Hashnode has RSS feeds that dev.to can auto-import, but I haven't wired it up yet.
Newsletter integration — Hashnode has a built-in newsletter feature. I want to connect it so new posts automatically go to subscribers.
Post templates — I'm developing a standard structure for project retrospectives (Problem → Approach → What Broke → Solution → Lessons). Having a template will cut writing time.
This is post number one. If you're reading this on dev.to — now you know how it got there.
This blog is called Observed — because the best insights come from paying close attention to what's actually happening, not what you expected to happen. More posts coming soon.
Find me: blog.yunasim.dev · dev.to · velog · LinkedIn · yunasim.dev