How hard can it be?

We subscribe to SaaS platforms, we pay for seats on AI interfaces, and we operate within the structural constraints someone else built for us. We call it flexibility, but it is often just dependency.

About two weeks ago, I decided to see what happened if I stopped renting and started owning. I wanted to move from no-code tools to a self-hosted “Personal Automation Lab” on a private server.

The goal was simple: Build a system that I controlled, for less than €10 a month, with minimal manual maintenance.

The question was: How hard can it be?

The hidden ceiling

I didn’t start from zero. My background is in the front-end and I understand the visible, the interactive, and the human-facing side of digital products. But the back-end - the servers, the silent logic of a VPS etc. remained a black box.

It turns out, the gap between “making it look right” and “making it work” is a not so small.

In the front-end, you manage the experience. In the back-end, you manage the environment. When you move to your own server, you are no longer just a user. You are the architect, the landlord, and the repairman.

Myth of “Vibe Coding”

There is a seductive narrative currently circulating around “vibe coding” - the idea that natural language has replaced syntax. The promise is that if you can describe a wish, the AI will grant the code. Like a genie.

This is a half-truth.

Vibe coding is not a shortcut for everyone. It democratizes building for those, who have an idea what is it they are trying to do. It enables them to become the architects to make it happen.

Using an LLM to generate a script is easy. Getting that script to survive a server reboot, load environment variables correctly, and talk to a secure database is not. The AI can provide the bricks, but it won’t design the foundation.

If you don’t understand the underlying structure - how Docker containers isolate processes or why a Caddyfile handles your SSL - you aren’t “vibe coding.” You are just guessing. To build something resilient, you still need to think structurally. The good news is, I knew nothing about Docker few days ago - but it was not that hard to learn the basics - just ask your favorite AI model to explain it to you.

From logic to system

My transition from no-code to a self-hosted stack was less about learning a new language and more about learning a new level of ownership.

The real challenge wasn’t the code itself. It was the orchestration.

• It looked like a logic error. It was usually a permissions issue.
• It looked like a script failure. It was usually a path mismatch in a container.

I had to stop thinking about “tools” and start thinking about “systems.”

I replaced manual configurations with a containerized stack managed via a single docker-compose file. I moved my entire management workflow into a browser-based interface, eliminating the need for a terminal in my daily work. If you don’t like the way AI is asking you to work, you just need to guide it to find a way that works for you.

The logic of ownership

This wasn’t a detour into a new career path. It was an exercise in understanding the tools we use every day. As marketing becomes increasingly technical, there is a danger in treating our core infrastructure as a “black box” handled by someone else.

The process of building this forced me to slow down. It required me to read error messages instead of closing them. It reminded me that the most powerful leverage isn’t found in the latest “AI feature,” but in the architecture that supports it.

If you don’t understand the environment, you can’t optimize the performance. And this does not apply only to the servers…

How hard was it? Hard enough to challenge me, easy enough to go through with it.

Now that I have the system in place, let’s see what can I make out of it.