Skip to content
Writing
·5 min read

I don't do tasks. I build systems.

Drafted through my n8n + AI pipeline, edited by me.

By the end of this you'll see the difference between someone who does your work and someone who removes it, and why that difference should change who you hire.

The mess

For most of my first years working remotely, the job was 'here is a list, work the list.' I would clear it, and tomorrow there would be a new one. The list never got shorter, because the person was the system. When that person was off, the work stopped. That is not a process. That is a single point of failure with a friendly face.

The wrong way people solve it

The instinct is to throw more hands at it. Hire another assistant, add another person to the list. That scales the cost in a straight line and scales the fragility with it. Now two people hold the process together instead of one, and a process held together by people is exactly the thing that breaks the week everyone is busy.

The system view

Take onboarding, the example I keep returning to from years running operations for a 150-attorney firm. A new hire signs. The system decides what access, which documents, and which team they belong to. It creates the accounts, templates, and scheduling automatically. A person confirms the edge cases, an alert fires if something is missing, and every step is logged. Onboarding stops being someone's job and becomes a system a person oversees.

Trigger (new hire signed) → Decision (which access, docs, team?) → Action (accounts and templates created) → Human review (confirm the edge cases) → Alert (something missing) → Record (every step logged).

What I would build

The system once, and then I stay to run it. Not a clever script that works in the demo, but the boring, valuable part: make it fail loudly, document itself, and survive the day nobody is watching. Anyone can ship the happy path. The difference between automation theatre and a real asset is everything that happens when the day goes sideways.

What can break

The demo-only automation that quietly fails the moment you look away. Logic only the builder understands, with no documentation, so it dies when they leave. No clear owner when it breaks at the wrong hour. An edge case nobody mapped. A system that hides its failures is worse than the manual process it replaced, because now you trust it.

What the business gets

The work leaves your plate and does not come back. Time that compounds instead of resetting every morning, a process that runs while you sleep, and a business that does not wobble when one person takes a week off.

If a system quietly fails when you look away, it was never a system. It was you, with extra steps.

Bring me the workflow your team holds together by hand. I'll tell you what I'd turn into a system first.

Building something this should run inside?

Book a systems call