I’m still in South America right now.
No laptop. No backups of backups. No “just in case” remote setup. I deliberately left with only my phone.
Which means everything back home either works without me, or it doesn’t.
That’s the experiment.
Before leaving, I realized something uncomfortable: a lot of things in my life only function because I personally prop them up. Projects. Admin. Workflows. Even small routines. Remove me from the loop, and friction appears everywhere.
So instead of trying to stay reachable, I tried something else.
I designed for absence.
Not just in code. In everything.
Start with the hard constraint
The rule was simple: I won’t be available.
No debugging production. No “quick fixes.” No hopping on Teams. No fiddling with CI from a hostel WiFi connection.
Once you accept that, design decisions become brutally clear.
If something needs manual intervention every week, it’s broken.
If knowledge only lives in your head, it’s fragile.
If a process requires your presence to move forward, it’s not a process. It’s you.
That applies just as much to work as it does to personal life.
Systems, not heroics
At work, this meant tightening contracts between components. Making sure deployments are predictable. Removing “temporary” Kubernetes complexity that had quietly become permanent. Writing things down. Automating boring steps. Making defaults safe.
I don’t want colleagues to need me. I want them to not notice I’m gone.
On the blog side, it meant scheduled posts, automated deploys, notifications that trigger from CI, and subscribers handled by external services. I write, push, disappear. Articles publish themselves. Emails go out. Drafts stay quiet.
No dashboards. No cron babysitting. No custom admin panels.
That’s not clever engineering. That’s restraint.
Apply the same thinking outside tech
This mindset leaks into everything once you start looking.
Bills are automated.
Important documents are where they belong, not scattered across devices.
Travel plans live in shared notes.
Recurring tasks don’t live in my memory. They live in systems.
Even relationships benefit. People know when I’ll be offline. Expectations are explicit. There’s no vague availability.
It sounds clinical, but it’s liberating.
You stop being the glue.
Absence is a design tool
Most systems are built assuming presence.
Someone will notice. Someone will fix it. Someone will remember.
That “someone” is usually you.
Removing yourself is the fastest way to surface hidden dependencies.
What breaks when you leave tells you exactly where your systems are brittle.
And the goal isn’t to eliminate responsibility. It’s to eliminate unnecessary coupling.
Good systems don’t require constant supervision.
They degrade gracefully. They fail loudly. They recover predictably.
And they don’t care where you are.
Optimize for not being needed
There’s a quiet ego in being indispensable.
It feels good to be the person everything runs through.
But it doesn’t scale. And it doesn’t travel well.
So this trip is partly rest, partly perspective, and partly a stress test.
If things keep moving while I’m gone, that’s success.
Not because I built something impressive.
But because I built something that doesn’t need me.
That’s the real goal.
Design systems that survive your absence.
