There’s a particular kind of guilt that comes with using a tool you know you could build yourself.

Last week I signed up for a hosted monitoring service. It took four minutes. Four minutes to have dashboards, alerting, uptime checks, and pretty graphs — things that would have taken me a weekend to set up from scratch with Prometheus and Grafana. And I felt… fine about it. Maybe even good.

But later that night, while the service quietly pinged my endpoints and I slept soundly, a small voice in the back of my head whispered: You’ve forgotten how to do this.

It wasn’t true. Not yet. But the voice wasn’t wrong about the direction I was heading.

The Convenience Gradient

Every technology exists on a spectrum between total control and total convenience. On one end, you’re compiling your own kernel. On the other, you’re tapping a button on your phone and a stranger brings you food.

Most of us live somewhere in the middle, and we migrate along this spectrum constantly — usually toward convenience, because that’s where the momentum is. Why configure Nginx when Vercel exists? Why manage a database when Supabase handles it? Why write a script when there’s a SaaS for that?

And honestly? Most of the time, that migration is rational. Your time has value. Not everything deserves a DIY approach. The person who self-hosts their email in 2026 isn’t a hero — they’re someone who enjoys troubleshooting SPF records at 2 AM.

But here’s the thing about convenience: it’s a gradient, not a switch. You don’t go from “competent” to “helpless” in one step. You slide. And the slide is so gentle that you don’t notice the ground changing beneath you until you need to stand on it.

The Skills You Forgot You Were Losing

I noticed this a few months ago when a friend asked me to help debug a Docker networking issue. I’ve written about Docker. I’ve taught Docker. I have opinions about Docker networking.

But my last three projects had all been deployed on managed platforms. PaaS. Serverless. The kind of thing where you push code and someone else worries about the network layer. And when I sat down to troubleshoot, I realized my instincts were dull. I was reaching for documentation I used to have in muscle memory. The concepts were still there, but the feel was gone.

This is what convenience takes from you — not knowledge, but fluency. You still know what a routing table is. You just can’t read one as quickly. You still understand DNS. You just don’t instinctively know which record type to check first.

Fluency is the difference between someone who speaks a language and someone who can look it up in a dictionary. And fluency only survives through use.

The Dependency Trap

There’s a second-order effect that’s even more insidious. When you build things yourself, you develop an intuitive understanding of how they work. You know where the failure points are. You know what breaks first under load, what corrupts data silently, what logs to check at 3 AM.

When you use a managed service, you outsource not just the work but the understanding. And that understanding is what lets you evaluate whether the service is actually good. Without it, you’re trusting the marketing page.

I’ve seen this play out in teams. A team adopts a managed queue service. It works great for two years. Then they hit a scaling issue and nobody on the team understands queuing theory well enough to diagnose it. They’re stuck — dependent on a tool they can’t reason about, waiting for support tickets to be answered.

Convenience doesn’t just make you weaker. It makes you vulnerable.

The Case for Strategic Inconvenience

I’m not arguing that you should self-host everything. That’s a different kind of foolishness — the kind that confuses suffering with virtue.

But I think there’s a case for what I’d call strategic inconvenience: deliberately choosing the harder path for the things that matter most to your core competency. Not because hard things are inherently better, but because the struggle is where the learning lives.

If you’re a web developer, maybe you don’t need to self-host your blog. But you should probably understand how HTTP works at the protocol level. If you’re a data scientist, maybe you don’t need to write your own linear algebra library. But you should understand what’s happening inside the black box.

The goal isn’t to reject convenience. It’s to choose it consciously rather than drift into it by default.

A Personal Rule

Here’s a rule I’ve been trying to follow, imperfectly: for every three things I outsource, I build one thing from scratch.

It doesn’t have to be production-grade. It doesn’t have to be good. It just has to be mine — something where I touch every layer, make every mistake, and learn every lesson.

Last month that meant writing a tiny HTTP server in Python. Not because the world needs another HTTP server, but because I wanted to remember what a socket actually is. The month before, I set up a bare-bones CI pipeline with shell scripts instead of GitHub Actions. It was ugly. It worked. I learned more in that weekend than in a month of clicking through managed CI dashboards.

The Irony

Here’s the irony that keeps me up at night: the people who understand this paradox best are usually the ones who’ve already lost the skills they’re trying to protect. The young engineer who’s never configured a Linux firewall doesn’t feel the loss because they never had the knowledge to begin with.

Which means the real danger isn’t that convenience makes you weak. It’s that it makes you forget what strong feels like.

So the next time a tool offers to make your life easier — and it will, constantly, relentlessly — ask yourself a simple question: What will I lose if I say yes?

If the answer is “nothing important,” then enjoy the convenience. You’ve earned it.

But if the answer is “the thing that makes me good at what I do” — maybe do it the hard way. Just this once. Just to remember.

Your future self will thank you. Probably at 3 AM, when the managed service is down and you’re the only one who knows how to fix it.