I'm a builder. I taught myself to run servers because freelancers kept burning my money.
West London, 2021. I was standing on a site holding a cup of tea that had gone cold an hour earlier, watching a crew argue about where a wall should go. That's my actual job. Schedules, suppliers, the kind of problems that only exist at 7am when half the crew hasn't shown up and the client is already phoning.
But my head was somewhere else. I'd been chewing on an idea for a classifieds platform for months. Not a grand vision, nothing with a business plan and projections. Just a gap I could see — a way to connect buyers and sellers that felt easier and more global than what was out there.
The problem was that I knew nothing about programming. And I mean nothing. I didn't know what a database was. I'd never written a line of code. My entire technical CV was "reasonably good at not breaking my own phone."
So I did what most people in my position do. I tried to buy my way in.
The expensive year
I found a ready-made classifieds script online. Looked professional, had features, didn't cost the earth. The smart shortcut, I told myself. Then I hired a freelancer to customise it. Then another one, when the first disappeared mid-project. Then another, when the second delivered something that worked on a good day and fell over on a bad one.
Here's the thing nobody warns you about hiring freelancers when you can't read code: you can't judge the work. You can't tell the difference between someone who wrote something clean and someone who duct-taped it together to last until the invoice clears. Both show you the same thing — a screen where the button does what the button's meant to do. So you pay, you say thanks, you move on. And three months later the button stops working and the freelancer's gone.
Meanwhile the bots had found me. Within weeks of going live, automated scripts were hammering the contact form, then the registration page, then the login. "It's normal," a freelancer told me. "Happens to everyone." What he didn't mention is that "happens to everyone" and "your server is set up to handle it" are very different sentences. Mine wasn't.
After about a year I did the maths on what I'd spent. The number made me feel a bit sick. And the product still wasn't right.
There was a specific evening — kitchen, about 11pm, laptop open, staring at another error I couldn't read — when I decided: either I figure this out myself, or it never launches. Not "I'll find better freelancers." Not "I'll get a technical co-founder." Just: I'm going to understand what's happening on my own server.
I had no idea what that actually involved.
Learning by breaking things
The first thing Linux teaches you is that it'll tell you exactly what's wrong. The second thing it teaches you is that understanding what it just told you takes a lot longer.
My first real SSH session was about fifteen minutes of typing things wrong, being told I didn't have permission to do them, and then being told I didn't have permission to give myself permission. I didn't quit — not because I'm brave, but because I was annoyed. It was my server. I was paying for it.
There's no syllabus when you learn this way. You learn whatever the problem in front of you needs. I learned SSH because I needed to get in. Linux commands because I needed to read logs. Fail2Ban because someone mentioned it in a forum thread about bots. I learned about web servers by breaking them — Nginx, then Apache, then LiteSpeed, then Varnish, then H2O for a bit. Eventually I found Caddy, which is what you get when someone builds a web server for people who aren't web server experts. Its config reads almost like plain English. I'm still on it today.
I should admit something. For the first two years I didn't use Git. Everyone uses Git. I took snapshots instead — a full snapshot through the hosting panel before touching anything I wasn't sure about. Slow, inelegant, not how professionals do it. But when things went badly wrong, and they did with some regularity, I could roll back. It's how I survived long enough to eventually learn the proper way.
My process, which I wouldn't have called a process at the time: describe the problem in plain language, as precisely as I can, into an AI chat window. Read what comes back. Try to understand what it's meant to do before I run it. Then run it on the live server, with a snapshot as the safety net. Every developer reading this is wincing. But every mistake had real consequences, and there's no better teacher than a mistake that actually costs you something.
The night that built Sentinel
The alert came in just after 3am. Server unresponsive. SSH timing out. CPU pinned at a level I'd never seen — not a spike, a sustained load that had been building for hours while I slept.
It was the Laravel app, being hit by a coordinated bot campaign that had found the contact form. No rate limiting. No CAPTCHA. To a script, an open door. Nearly a million emails went out before I shut it down. The server got blacklisted — not by one service, by several. I spent the next week in a state of focused misery: site by day, then evenings contacting blacklist operators, waiting on reviews, and putting in the things that should have been there from the start. Rate limiting on every form. CAPTCHA where it mattered. SPF, DKIM, DMARC done properly. Monitoring on outbound email.
While I was fixing all that, I started a list of everything that could go wrong on a server like mine and what would have to be true to catch it. Nothing I could find did all of it. So I started building it myself.
The first version was not impressive — a Python script on a cron job, checking a list of things every few minutes. But it ran, and it found stuff. A service that had quietly crashed seven times in an hour. A query taking twelve seconds. Disk usage creeping toward full. Small things. The kind that become big things if nobody's watching. I was watching.
That tool eventually became Sentinel. As I write this, its blocked-attacks counter — every banned IP, every blocked request, every Fail2Ban trigger since it started running — reads 283,103.
What changed
For a long time I was still slow. Every feature took too long. The gap between having an idea and making it real was still too wide. Then the way I worked with AI changed — less "give me the answer," more "here's what exists, here's what I need to exist, here's how I'll know it works." I could think out loud and have the vague bits noticed and questioned. For someone still building the mental models that experienced developers have on autopilot, that was the unlock.
I also made a decision that felt dramatic and now feels obvious: I threw away the Laravel codebase I'd inherited from freelancers and didn't fully understand. Over a few months I moved everything to React, TypeScript, tRPC and Node. It was faster and cleaner, and I understood every part of it — because I'd either built it or understood what the AI built and why. At one point I rebuilt one of my smaller sites in about six hours. Eighteen months earlier that would have been unthinkable.
Where I am now
The alarm still goes off at 5:45am. Site by seven. By the time most tech founders are reaching for their first coffee, I've been working for hours. The construction company runs well and I find it grounding — at the end of a day there's something real in the world that wasn't there in the morning.
The software side now has a handful of live products, and every one of them started as a tool I needed rather than a product I planned: Sentinel for watching servers, the classifieds platform that was the original idea finally built properly, a spam filter that came straight out of that contact-form disaster, and a couple of tools for content. Sentinel has a free tier for a single server and paid plans beyond that — the details are on sentinel-ai.info if you run servers and the 3am story made you wince in recognition.
If you've got an idea you haven't started because you don't have the technical background — start anyway. Not with a plan to learn everything first. Just start, with whatever you've got. I didn't learn to run a server and then build things. I built things and learned to run a server because I had to. The knowledge follows the doing, not the other way round.
I still keep steel-toe boots by the door.
Top comments (0)