There hasn’t been a new blog post here since June. I did have a lot to write about, but I was busy getting this website up and running — again. What started as a fairly small personal project turned into a surprisingly good exercise in many of the things that I’m surrounded with in my professional life: making decisions that scale, dealing with limitations, working with tools that don’t fit into the game, changing direction, migrating content, working with AI, relying on documentation and, eventually, bringing something live before it feels completely finished.

About a decision that didn’t scale

A while ago, I realized the service I’d chosen for my website wasn’t a good fit anymore. I’d hit a limit on adding sub-pages, which was essential for publishing blog posts. So I was forced to change direction. That meant freeing up the time to deal with it, looking at different options, figuring out what I actually needed, and validating that the alternative would work. Eventually, I decided to build the website myself. Working in my comfort zone with Markdown and GitHub and having full control was more important to me than having the convenience of an all-in-one service. Of course, “having full control” also means having responsibility for all the things that the service used to take care of for you.

That became apparent fairly quickly.

Suddenly, I was the person who didn’t know what to do

There’s a particular kind of frustration in being blocked by something you don’t understand: you know what you want to achieve, but not the next step. That’s different from being stuck on a problem in your own area of expertise, where you can usually narrow it down and work through it.

I experienced plenty of that during the rebuild: migrating the content was easy, but understanding how the technical pieces fit together, and designing something responsive that looked professional, was not. Since I didn’t have endless time to learn web development from scratch, I did what most people would probably do today: I asked AI for help.

It was incredibly useful. It explained things, suggested solutions and helped me move forward much faster than I could have on my own. But it also confirmed once again what I experience time and time again in my professional life: When you know enough about a subject, you can usually spot when an answer doesn’t make sense. When you don’t, you have a problem: who tells you whether the answer is actually right?

AI can be an excellent assistant, but it doesn’t remove the need for expertise. It changes where you need that expertise. Sometimes you need to know how to solve the problem yourself. Sometimes you need to know enough to recognize whether the proposed solution is plausible. And sometimes, when you are completely outside your area, you need something else to rely on.

For me, that something was good documentation.

The importance of accurate, reliable, and accessible documentation

The best example was transferring my domain. I knew what I needed to do. I had absolutely no idea how to do it.

I had to navigate settings and concepts that were completely unfamiliar to me, and I needed to do it carefully because getting something wrong could mean that my website disappeared. I relied heavily on documentation and on AI helping me interpret it and turn it into practical steps. And suddenly, something I have spent years talking about professionally became very real for me personally: documentation isn’t just content that happens to exist somewhere. When you genuinely don’t know what you’re doing, it becomes part of the product experience.

The information needs to be correct, accessible, and detailed enough to help someone make the right decision — and ideally written so that someone, or an AI helping them, can turn it into action.

I just hadn’t had to rely on it quite so directly before — not until I was sitting in front of a domain configuration screen thinking, “I have absolutely no idea what this means, please tell me what to click.”

That feeling when the website is down for a while

And that feeling, when it’s back up again!

At some point during all of this, the website wasn’t reachable anymore. That was probably the moment when the project stopped feeling like a fun side project and started feeling like a real product.

It is surprisingly unsettling when something you have built yourself suddenly isn’t there. I knew this was part of the domain transfer. I also knew that nobody was going to lose their job because my personal website was offline. But emotionally, that didn’t make it particularly less annoying. I didn’t care about the layout, the colors, or any of the details I’d been happily tweaking before. I just wanted the damn thing to work.

And when it happened again, the relief was nothing compared to the actual problem. I felt like it was Christmas and Easter rolled into one, and I was as happy as a little kid.

That episode was another useful reminder of something that can easily get lost when you’re working on digital products: reliability matters because people experience the result, not the effort that went into building it. Nobody visiting a website cares how elegant the implementation is if the page doesn’t load.

Good enough is sometimes exactly what you need

There was another lesson in the project that became vital for me: the value of an MVP. I could still be working on the website now. There’s always something to improve, rewrite, redesign, or polish (yes, my pixelated portrait is on the short list). But waiting until every detail felt right would also mean nobody would ever see it.

So I decided that it was good enough to publish and that I could improve it afterwards. And I did.

That doesn’t mean I think quality is overrated. Quite the opposite. But there is a point at which another round of internal polishing produces less value than simply putting something in front of real people. You learn something different once a product actually exists in the world. You discover what matters, what doesn’t, what you want to change, and what you are perfectly happy to leave alone.

Nobody gets everything right the first time. Sometimes the most useful thing you can do is publish the first version and start learning from there.

Lessons learned on very familiar problems

Looking back, I’m struck by how many familiar patterns showed up in such a small project — the same kind of decisions, blocks, and dependencies I’m surrounded with professionally, just at a much smaller scale.

In a company, all of these things can become expensive very quickly. A service that doesn’t scale, a team that is blocked, a migration that takes longer than expected, missing or unreliable documentation, unclear responsibilities or a solution that seemed fine until people actually started using it. These are not just minor inconveniences when hundreds or thousands of people are affected.

Vibing with pride

After all of that, the strongest feeling is: pride. The website is live. I lost some time along the way and learned quite a few things the hard way. But I also gained experience that I couldn’t have gotten by simply reading about these problems. And this sharpened my understanding of what some of these things actually feel like from the other side.

So that’s where I’ve been since June. I wasn’t writing new blog posts because I was busy making the website work.

And now that it does, I’m quite happy to be back.