Six years from idea to first post

The idea that wouldn't go away

Sometime in mid-2020, deep in COVID lockdown season, I decided I wanted my own blog. I had zero frontend experience at the time. I was building Java applications with Spring Boot and had no idea how to put together a website. But I had this itch to write longer-form content for fellow developers, to share how I approach problems and learn how others do the same.

I love learning by doing, so naturally I thought, "I'll just build it myself. How hard can it be?"

Spoiler: it took a while. And the path wasn't straight.

For a long time, I didn't act on it. I had university coursework to finish and a career to get started. The idea went into the "someday" folder in my head, right next to "learn UX design" and "build a home server." It never felt like the right moment.

It stayed there for about six years.

Writing for someone else's blog

Before I had my own platform, I did publish something. I wrote an article about clean unit tests with Mockito (opens in a new tab) for Reflectoring.io. That experience stuck with me more than I expected.

Tom Hombergs (opens in a new tab) helped me turn my rough draft into a polished article. He gave me feedback on the structure, the examples, the wording. The kind of editorial guidance that makes you realize how much better your writing can get when someone pushes back on it.

But the writing itself was the real reward. Not in a "I love sitting at a keyboard for hours" way, but because organizing what I knew about Mockito into a coherent article forced me to actually understand it. I found gaps in my own knowledge. I went back and read source code I'd been using for months without a second thought. By the time I published, I genuinely understood the library better than before.

And then seeing my name on a well-known developer blogging site? I won't pretend that didn't feel good. It did. It felt really good.

That article made me want more. Not because Reflectoring wasn't great (it was), but because I wanted to choose my own topics, my own format, my own pace.

The bookmark folder that started it all

I'm a collector. Not of anything physical, but of articles. I follow people like Dan Vega (opens in a new tab) and Thomas Vitale (opens in a new tab), along with a bunch of Java Champions whose writing I've learned from over the years. I have a bookmark folder that's gotten embarrassingly large: well over a hundred articles about architecture decisions, testing strategies, framework deep-dives.

At some point I realized I wasn't just bookmarking things to reference later. I was studying how these people wrote. How they explained trade-offs. How they made technical content feel like a conversation instead of documentation.

I wanted to do that too. If you scroll down, you'll find some of the blogs and articles that shaped how I think about technical writing in the resources section below.

Every framework fell short

So I tried to build the blog. Multiple times. I went looking for open-source blog frameworks I could self-host, something dockerized and ready to go.

I found options. Quite a few, actually. But every single one had the same problem: something always felt off.

Some had too much overhead for what should be a simple personal site. Others weren't straightforward to set up, with configuration spread across multiple files, implicit conventions you had to discover by trial and error. Many forced trade-offs in functionality that didn't make sense for my use case. And the ones that did work well enough? They locked you into someone else's design system. You'd pick a theme, and that was your look. Customizing beyond the surface meant fighting the framework instead of building with it.

The gap between what I saw on developer blogs I admired and what these tools produced felt impossible to close with my frontend skills at the time.

So I gave up. More than once. Each time I'd tell myself "maybe next year" and go back to building REST APIs.

Then it actually happened

I don't have a dramatic turning point to share here. No montage. I just kept working, picked up more frontend experience through my day job, and one day the gap didn't feel impossible anymore. The things I'd struggled with, like layout, responsive design, and component architecture, had quietly become skills I could lean on.

So I started building.

The site runs on Next.js 16 with TypeScript and Tailwind CSS 4. Blog posts are MDX files processed by Velite at build time into a type-safe content layer. Static export, served from S3 behind CloudFront (it started out on nginx). Nothing fancy in the architecture, but it does exactly what I need.

Beyond the blog, the site has my CV and a resources section where I'm collecting the tools, blogs, and articles I keep going back to. Basically, I'm turning that bookmark folder into something useful for other people too.

Why bother writing?

I'm not here to position myself as an authority or to claim I've found the one right way to do things. I'm a software architect who learns things at work, reads a lot, and occasionally has thoughts worth more than 280 characters.

What I've noticed is that when you put ideas out there, people respond. They share their own experience, push back on things they see differently, add context you missed. That's the part I'm most interested in. Writing is how I think through a topic properly, and the conversation that follows is how I learn whether my thinking holds up.

I plan to write about the stuff I deal with day to day: software architecture and system design, Java and Spring Boot in production, patterns that actually work in practice, the frontend world I'm still finding my footing in, and tools that make engineering teams work better together.

No publishing schedule. I write when I have something worth saying.

If you've been putting it off

If you've had a blog idea sitting in the back of your head for a while, I get it. Mine sat there for six years. There's always a reason to wait: the framework isn't right, the design isn't good enough, you don't have enough to say yet.

Here's the thing I keep coming back to: none of those reasons went away on their own. I just eventually decided that shipping something imperfect was better than waiting for perfect conditions that weren't coming.

If you do end up starting, I'd genuinely like to read what you write.