Relaunching the website, and accidentally writing a CMS

If you know me even just a little bit, you already know how this story goes.

Normal people wake up one day, look at their website, think “hm, this could use a refresh”, pick a new theme, move some blocks around, maybe optimize a few images, and call it a day.

I, on the other hand, looked at my website and thought: “yes, the design could use a refresh, but what if I also wrote an entirely new CMS in Rust while I am at it?”

Because apparently I do not really do small relaunches. I do archaeological excavations with side quests.

The old site had a very decent run

The previous version of my website had been with me for a long time. In internet years, it was not just old, it was basically eligible for a management role. The version you can still find in the 2014 web archive snapshot went live around 2013 to 2014, and for what it was supposed to do, it served me remarkably well.

It had personality. It had movement. It had that very specific energy of a time when we all thought a good website absolutely needed animated transitions, a couple of plugins, and just enough JavaScript to make future-you mildly uncomfortable.

And honestly, I loved it.

That is what made this relaunch weirdly difficult.

Because the old page was not a disaster. It was not one of those projects where you open the source code, gasp audibly, and immediately call for fire. It had simply become a time capsule. Which is charming in a museum, but not necessarily the long-term strategy for your professional homepage.

At some point I had to admit that the website still represented a version of me that was very real once, but increasingly less current now. The internet had moved on. Browsers had moved on. My work had moved on. Even my taste in whitespace had moved on.

And so, after only a completely reasonable amount of procrastination that definitely did not span years, it was time.

Personal websites are ridiculous projects

There is something uniquely absurd about personal websites.

They are small enough that you think: “I can knock this out over a weekend.”

They are personal enough that every sentence suddenly turns into an identity crisis.

What exactly do you put on a homepage once you have done a few different things in your career? How much of it should sound serious? How much should sound like you? How polished is too polished before it starts to feel like a brochure for a person who probably says things like “let’s take this offline”?

A company website can hide behind corporate language. A product page can hide behind features. A personal website has to stand there awkwardly under fluorescent lighting and say: “hello, this is me, apparently.”

That alone would have been enough work already.

But unfortunately, somewhere between “let’s update the page” and “I should restructure some content” I did what I always do: I started questioning the machinery behind it.

Of course I wrote a new CMS

And here we are.

Because of course I would not just relaunch the website. I would also write a brand new CMS. A CMS, or Content Management System, is the software that manages the content of a website: pages, blog posts, images, metadata, and all the little pieces that have to end up in the right place without you editing raw HTML by hand every time.

Not because the world was crying out for another CMS. The world, to be fair, was not. If anything, the world has made its position on CMSes pretty clear: it would prefer fewer of them.

But I wanted something that fit this site better than the usual choices.

I did not want to wrestle a giant system into behaving like a small, content-driven website. I did not want an admin backend with seventeen menus, a plugin ecosystem held together by hope, or a build pipeline that feels like I have to perform a ritual before publishing a typo fix.

I wanted content in files. Routing I can understand without consulting three layers of abstractions. Templates that stay close to HTML. A build process that is fast, boring, and transparent in the best possible way.

So I wrote ferrosite.

That is the new engine behind this site.

Which sounds elegant and intentional now, but in reality the process was more like this:

0. Hugo (the CMS of the old website) is too complicated, I don’t need that
1. Oh I want to refresh the website.
2. The current setup is a bit annoying.
3. I could simplify that.
4. Oh no, I am designing a content model.
5. Oh no, I am building a pipeline.
6. Oh no, this is a CMS now.

This is, in hindsight, an extremely predictable outcome.

I like understanding my tools all the way down to the point where I probably should have stopped much earlier. Some people buy a shelf. I become emotionally involved with the idea of first building a sawmill. Same genre of mistake.

Why ferrosite exists

The funny part is that writing ferrosite was not even about ambition. It was mostly about irritation.

A good amount of software starts that way. Not with a grand vision, but with a developer muttering “why is this so weird?” often enough that eventually an entire project appears. I was starting with Hugo, the CMS I was using for the old homepage, and somehow I felt I always had to jump hoops.

ferrosite grew out of a pretty simple idea: the infrastructure behind a small website should not be more complicated than the website itself.

That sounds obvious, but modern web tooling has a special talent for turning obvious things into build graphs.

For this site, I wanted a setup that:

• keeps content portable from Hugo
• makes templates easy to reason about
• does not hide routing behind magic
• builds fast
• ships even faster
• leaves enough room to preserve the character of the older site without preserving all of its technical fossils

And that last part mattered a lot.

Because this relaunch was never supposed to erase the old website. I did not want to sandblast away all the rough edges until the result looked like every second portfolio site on the internet, with the same oversized headline, the same three floating gradient blobs, and the same suspicious promise of being passionate about innovation.

I wanted the new version to still feel like my website.

Just with fewer historical artifacts lurking under the hood.

Also, I’m very happy I can ferrosite run my website and ferrosite ship it when I’m happy with it. Sure, I could set up a github workflow, dance the dance, for 80 pages of static html and a contact form. Or I have a cli that has a command for that.

A relaunch is also a small act of honesty

I think that is what made this worth doing.

A personal website is, in a way, a long-running public note to self. It shows what you cared about enough to publish, how you wanted to present your work, and what kind of technological decisions felt reasonable to you at a particular point in time.

Looking back at the 2013/2014 version is honestly a bit like opening an old photo album and noticing your haircut before anything else. You are still recognizably the same person, but there are choices in there that can only be explained by the era.

And that is fine.

That older website got me through a lot. New jobs, new ideas, new experiments, blog posts, projects, and all the strange turns a career in tech tends to take when you are curious enough to say yes to things that later become entire chapters of your life.

But at some point, keeping the old site unchanged stops being consistency and starts becoming avoidance. It becomes a polite way of saying: “I will update this later”, repeated for several years until “later” has become a historical period.

So this relaunch is really just me finally acting on something I had known for a while: the site needed to catch up.

The reassuring part

The reassuring part is that even after all this, the result is still just a website.

Not a platform. Not a revolutionary digital experience. Not a paradigm shift in personal branding.

Just a website that is more current, easier to maintain, truer to what I do today, and built on tooling that I actually enjoy working with.

Which is, frankly, enough.

If you are reading this and thinking “this man wanted to repaint a wall and instead built a brick factory”, then yes. That is an accurate summary of events.

But to be fair, the brick factory is quite nice.

And more importantly, it means this page is now running on something I understand end to end. Content, templates, build, deployment, all of it. No mystery machinery. No accidental complexity I have to tiptoe around six months from now when I just want to fix a headline or publish a post.

That alone makes the whole thing worth it.

So, what changed?

The design is cleaner. The structure is better. The content is more intentional. The engine underneath is new. The spirit, I hope, is still recognizably mine.

Which maybe is the best outcome a relaunch can have.

The old site had a good run. A really good one.

But it was built in the 2013 to 2014 era, and no matter how attached I was to it, it was time for an update.

So I updated it.

In the completely normal way.

By writing a new CMS first.