The Case for Boring Infrastructure

The industry decided that simple infrastructure is for beginners and distributed complexity is for serious engineers. I disagree.
The Case for Boring Infrastructure
Photo by Samuel Ramos / Unsplash

I default to a VPS. Not because I'm old-fashioned. Because I like to understand what I'm running.

A VPS, a reverse proxy, a database I actually know, logs I can read, a deploy script I wrote. That's usually the whole stack. I can SSH in, poke around, fix things, move things, and understand the full chain from domain to database. That's not primitive. Or is primitive. It's however I need/want it to be. That's the point. I can even migrate the whole thing to another provider in a single day, maybe less.

The industry somehow decided this is embarrassing. That simple infrastructure is for beginners and distributed complexity is for serious engineers. I disagree. I've seen pre-revenue products split across a frontend platform, a managed database, third-party auth, a queue, a storage bucket, a serverless layer, an observability tool, and a billing integration before a single real user showed up. When something breaks in that setup, you open seven dashboards from six providers and start guessing. The status page says green. Users can't even say, because you probably forgot to route something.

Every service you add is a new attack surface, a new pricing model, a new failure mode, and another thing that can change while you were asleep. Dependencies should earn their place.

There's also a bonus: AI tooling actually works well on a boring stack. When everything lives on one machine, an AI assistant can SSH in, read logs, inspect configs, and understand what's happening. It can actually help. Spread the same app across eight providers with eight auth models and eight APIs and your AI assistant is just reading dashboards with you. Equally useless. I don't mean "unleash AI to do magic" - I mean AI as a helper. If AI can make sense of the setup - so do you.

Use cloud when it clearly solves your problem. Spiky workloads, global latency requirements, compliance needs. All those reasons are real and more reasons exist and VPS really might be wrong pick in those cases. But "it looks better on a CV" is not a reason. And neither is "that's what serious engineers do".

The app might run on a Raspberry Pi hidden in a gym closet on public wifi for all I care, as long as the user is happy when he is using the app and does not experience any issues.

Most small products die because nobody wanted them, or the founder burned out. I don't know a single one that died because it ran on a VPS.

And if your app can't survive a basic server setup then no amount of infrastructure will save it. You can't Kubernetes your way out of bad engineering. You can only make it more expensive.

Subscribe to Technikatsu newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox. It's free!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!