I'm Sorry, It's Not You... It's Me

I got a server.

It's not much — a little box somewhere in a data center humming along at a few bucks a month. No fancy SLA. No enterprise support contract. Just me, a terminal, and Dokploy.

Here's the thing nobody tells you about being the person who builds automations for other people: you are the single point of failure.

You build the pipeline. You deploy it. You monitor it. You fix it when it breaks. The client doesn't have a system — they have you with a laptop and a good attitude. And that scales like shit.

To be honest, I've been a single point of failure. Plus I don't want people constantly treating me like I'm IT help. You shouldn't be seeing me in your office.

The goal isn't to make yourself indispensable. The goal is the exact opposite.

Remove yourself from the equation.

Clients Don't Want You

Let me be direct. Your clients don't wake up in the morning thinking "I hope Lubasi is having a great day and is available to press the button."

They want the report on their desk. They want the pipeline to run. They want the data to be fresh. They want the problem to stay solved. They don't care how it happens as long as it happens.

The moment you make yourself essential to the operation, you've created a single point of failure that bills by the hour. And the client knows it. They feel it. That's why they hesitate to fully commit to your automation — because they're not buying a system, they're renting a person.

I realised this when I noticed a pattern. Every time I built something good for a client, they'd ask the same question in different words: "What happens when you're not around?"

The answer used to be "call me." Now it's "nothing — it just runs."

That distinction is the entire business model.

Dokploy Changed the Game

I'm running everything on Dokploy. It's an open-source deployment platform that sits on top of Docker and Traefik. Think Google Cloud/AWS but you own the box.

The UX is dead simple. Connect your Git repo, pick a branch, click deploy. It builds the container, sets up the reverse proxy, provisions the SSL — all of it.

Why not rawdog deployment? Because I don't want to SSH into a box to fix a deployment at 11 PM. Dokploy gives me a dashboard. I can redeploy, rollback, check logs, manage environment variables, all from a browser. On my phone if I have to.

The less friction between "I have a fix" and "the fix is live," the less I have to be present for the system to survive.

You tell me a problem. I push an update, redeploy the change, and you get a message back that I fixed it. We both go on with our lives. No visit. No call. No "can you just check something while you're here."

This approach is a perfect fit for clients who want on-premise solutions — data stays local, everything runs in their office, but I can update it over the wire. Think of it like a remote link to their office PC. They get the security of an in-house system without needing me to show up every time something needs a tweak.

What's Actually Running

Right now on the box, all deployed through Dokploy:

• Uptime Kuma — monitoring everything. My little dashboard of shame. If something's red, I know before the client does.
• Umami — the privacy-friendly analytics I talked about last time
• Client automation pipelines — the real payload. Data processing, report generation, scheduled jobs that land in inboxes without anyone pressing a button
• PostgreSQL — because if you read my last post, you know I'm not about that spreadsheet life

Everything is containerised. Everything has a health check. Everything either runs or it doesn't — and if it doesn't, the monitoring catches it and I get notified.

The Goal Is to Be Optional

The unsexy truth about selling automation is that your best sale is the one where they forget you exist.

If a client thinks about you every day, 😝😝 , you haven't automated anything. You've just renamed "manual process" to "call Lubasi." That's not a solution — it's a relationship that feels like a leash on both sides.

The real metric isn't "how much value did I deliver." It's "how much of that value survives if I get hit by a bus tomorrow." Crazy. But accurate.

When I deploy something now, I ask myself: if I never touched this again, would it keep running for six months? If the answer is no, I haven't finished.

Why Bother?

Because the alternative is being the guy who's "really good at fixing things" — which means things have to break for you to be valuable. That's a terrible business model. You want things not to break. You want them to run so quietly that nobody thinks about them.

That's what a Server with Dokploy and Uptime Kuma gets you. A place where things live and run and keep running. Where you can push a fix from your phone while waiting for coffee. Where the client gets their report without knowing or caring how it got there.

You're not the product. The running system is the product. And the running system needs less of you every day.

P.S. — The uptime page is live at uptime.lubasiverse.com. The goal is for it to be boring. Boring is good.