Choosing a Blog Platform (Without Overthinking It)
Before writing a single post, I had to answer a surprisingly annoying question:
Where should this blog live?
I had a few hard constraints from the start:
it had to be free
it had to be easy to use
it had to make sense for technical writing
it should have API access
and ideally, it shouldn’t lock me into someone else’s ecosystem
This post is about how I evaluated my options, what I cared about, and why I ended up with the setup I did.
The Non‑Negotiables
Some decisions are easier when you draw a box around them early.
For me:
Paid plans were out — not “later”, not “maybe”, just out
I wanted to write in Markdown
I wanted to retain ownership of my content
Automation and scripting mattered more than themes and layouts
That immediately narrowed the field.
The Shortlist
After filtering out platforms that were either too locked-down or too generic, I was left with a handful of viable options:
Hashnode
Medium
WordPress.com (free tier)
Blogger
GitHub Pages + a static site generator
At a high level, all of these let you publish text on the internet.
The differences only show up once you care about how you publish.
Why API Access Mattered
One thing I’ve learned the hard way:
manual workflows don’t scale, even for side projects.
I didn’t need a complex CMS, but I did want:
the option to publish programmatically
the ability to query my own posts
a clean path to cross‑posting or automation later
That single requirement quietly eliminated a few popular platforms.
Medium, for example, is great for writing — but there’s no official public publishing API.
Blogger is simple, but offers very little in terms of modern automation.
WordPress.com’s free tier limits what you can really do.
That left two serious contenders.
The Final Two: Hashnode vs Dev.to
At this point, the decision wasn’t about “which is better”, but what role each platform plays.
Hashnode: The Home Base
Hashnode feels like a personal tech blog first, and a platform second.
What stood out:
free custom domain support
Markdown‑first workflow
strong sense of content ownership
a GraphQL API that allows real integration work
The GraphQL API is more complex than a simple REST endpoint, but it’s also more powerful.
If I want to build tooling around my content later, Hashnode makes that possible.
The trade‑off is reach. The built‑in audience is smaller, and engagement is quieter.
Dev.to: The Distribution Channel
Dev.to feels more like a social platform than a personal site — and that’s not a bad thing.
What stood out:
a large, active developer audience
fast publishing and strong discovery
a very approachable REST API
excellent support for cross‑posting
Dev.to is optimized for visibility and conversation.
You give up layout control and domain ownership, but you gain reach.
For short posts, opinions, and updates, it works extremely well.
The Decision
The conclusion was obvious once I stopped treating this as a single‑platform choice.
Hashnode is the canonical blog.
Dev.to is the amplifier.
That gives me:
ownership and structure on Hashnode
reach and feedback on Dev.to
automation options on both
zero monthly cost
Most importantly, it lets me focus on writing instead of platform mechanics.
Why This Matters Less Than You Think
The platform choice matters — but not as much as starting.
Every option here is “good enough” if you’re actually publishing.
The real mistake is waiting for the perfect setup before writing the first post.
This setup gives me enough flexibility to grow, without committing me to complexity I don’t need yet.
And that’s usually a good sign.
If you’ve gone through a similar decision, I’d be interested in what tipped the scales for you. Ownership? Reach? Simplicity?