How I Built My Developer Blog: Tools, Trade-offs, and Lessons Learned

Why I Wanted a Developer Blog
As my career in software engineering evolves, I wanted a space to:
- Share learnings.
- Reflect on my side projects.
- Share my industry thoughts and views.
- Build out my profile.
- Low cost / free.
I already had a Substack, but hadn’t used it much and it was a bit unfocused (I started my substack a year ish ago as a kind of catch all blog to share broad thoughts).
It was easy to get started on Substack, but I found its push toward monetisation a bit off-putting (I don’t want to paywall my content). I wanted a clean, developer-focused blog, without aggressive paywalls and email capture and a bit more customisability.
So I started exploring other options...
Considering Static Sites and GitHub Pages
I wanted to keep it simple, and keep it low cost! A static site hosted via GitHub Pages is free, fast, and version-controlled.
After a bit of searching I found Bootstrap and found a lot of nice, free templates, and started tinkering...
What I liked:
- Simple to set up
- Great for a no-frills landing page
- Loads of community templates
What I didn’t:
- I could see routing and organising posts becoming a pain quickly.
- Didn't want to spend time writing boilerplate or patching together workarounds.
- I could see it as easy to outgrow for more complex content e.g filtering tags, components, routing etc.
This made me stop and ask: what do I really need?
Step 2: Defining My Requirements
Roughly, I needed:
- A standard blog layout (posts, tags, nav)
- Markdown support
- Easy updates and routing
- Custom domain
- Low or no cost
I didn’t want to spend too much time maintaining infrastructure, but something a bit more powerful and flexible, that could accommodate more complex and dynamic elements
Step 3: Trying Astro
Astro caught my eye. It’s lightweight, fast, and developer-friendly. I built a minimal Astro blog, deployed it via GitHub Pages using GitHub Actions. Quite fun. Easy. I avoided something like Next.js + Vercel - simply for cost and rendering speed (and maybe I was a little lured by new and shiny)...
I built a little Astro blog (not a looker!) to familiarise myself with the framework, test out GitHub actions and deploy to pages and Astro basics. You can see my GitRepo here and the live site here. If it was my main production site I'd have started with their free templates, to avoid wasting time on styling etc...
What I liked:
- Nice getting started guide
- Fast static generation
- Easy GitHub deployment
- Markdown-friendly
- More flexibility than Bootstrap - eg more powerful links, react like components for things like nav bars, markdown support to easily turn a folder of posts into a cms like sortable post structure.
- Lots of free templates
What I didn’t:
- No native newsletter or analytics.
- Required a bit more wiring up (e.g., custom routing, metadata)
- Still felt like I’d be spending time tweaking instead of writing, especially when I added up my requirements (analytics - quite easy via Google, newsletters etc).
If I was building a custom blog or had time to spare, Astro would be a great choice - I could see it being fun, powerful and connecting something like PostHog, for more privacy centric analytics.
Step 4: Substack Again? Almost...
I briefly considered going back to Substack—its built-in email support was tempting—but the paywall-first model, low customisability, broad focus, didn’t feel right for what I wanted.
Step 5: Finding Hashnode
Eventually, I discovered Hashnode. It ticked nearly all my boxes:
- Custom domain support
- Free to use
- Newsletter integration
- Built-in analytics
- Developer-focused (Markdown, GitHub embeds, etc.)
- No hard sell on monetisation
- Customisable for the future, but easy to set up.
- Developer focused community
- Good for SEO
It felt like the right middle ground: more power and polish than Substack, less setup than Astro or Bootstrap... and importantly I wanted to allocate more time to building cool things... so I took the leap, got on Hashnode and published my first post (this one!).
Ultimately, I learned that clear requirements—even for personal projects—can save a lot of time building, researching, and second-guessing.
Lessons Learned
I approached this like a real project: defining requirements, prototyping, testing tools, iterating, refining my requirements and deciding what to use based on value vs. effort.
Here's my learning summary:
- Specs matter: even for personal projects, define your requirements early. It’ll save you time and indecision later. Specs are always a little emergent in that discovery phase, but it pays to define the key outcomes, upfront (as well as you can).
- Bootstrap is solid for simple landing pages, but not ideal for content-heavy blogs.
- Astro is brilliant, especially if you want to build something fully custom and fast.
- Substack is great if you're newsletter/ paywall first, want a broader audience **but not if you want control.
- Hashnode hits the sweet spot for developer blogs with minimal setup and good features.
What’s Next
I’ll be using this blog to share what I’m learning, document side projects, and reflect on my journey into software engineering, sharing my thoughts on the industry.
You can sign up for email updates here or follow my GitHub as I build stuff 🙂
Subscribe to my newsletter
Read articles from Dileepa Ranawake directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
