People ask me what I've automated across my businesses, and it's the wrong question. The interesting question isn't what can be automated — almost everything can be, badly — it's what should be, and what I refuse to hand over no matter how good the tooling gets.
I run five ventures without a co-founder or full-time employees. Automation is the only reason that's possible. But automation is also the thing most likely to quietly break everything while looking like it's working. I've lived both sides. Here's the actual decision framework I use, including the parts I got wrong first.
The wrong question: "What should I automate?"
When founders ask what to automate, they're usually really asking one of two things: "how do I get more hours back?" or "how do I stop doing the stuff I hate?" Both are reasonable. Both lead to bad automation decisions.
Automating to get hours back usually means automating the thing that's most annoying, not the thing that's most expensive. I spent real time early on automating parts of my workflow that took twenty minutes a week while ignoring a manual process that ate six hours. The annoying thing got automated because it was visible. The expensive thing stayed manual because it was boring to think about.
Automating to avoid hated work is worse, because the work you hate is often the work that contains the most information. I hated lead follow-up. It felt repetitive and slightly desperate. So it was a natural automation candidate — and automating it early would have been a mistake, because doing it manually for months taught me exactly what a good follow-up looks like, which objections actually matter, and when persistence turns into pestering. You can't encode judgment you haven't developed yet.
So I stopped asking "what should I automate?" and started asking three different questions instead.
The three-question filter
Every automation decision I make now goes through the same three questions, in order:
1. Does it happen often enough to be worth the build?
Automation has a fixed cost (building it, testing it) and a maintenance cost (it will break, and you'll have to fix it). The payback only works if the task recurs. My rule of thumb: if I haven't done it manually at least a dozen times, I don't automate it yet. A dozen repetitions teaches me the edge cases. Fewer than that and I'm automating my guess about the process, not the process.
This rule has saved me more times than I can count. The temptation is always to automate the novel, interesting problem. The payoff is almost always in the boring, repeated one.
2. Is the failure mode acceptable?
Every automation fails eventually. The question is what happens when it does. I sort automations into two buckets: failures I notice immediately, and failures that are silent.
A social media post that fails to publish? I notice — the queue is empty, or someone mentions it. Acceptable failure mode. A lead routing rule that silently drops a category of inquiries into a folder nobody checks? I might not notice for weeks. Unacceptable — or rather, acceptable only with a monitoring layer that converts the silent failure into a loud one.
This is the question most people skip, and it's the one that matters most. I'll come back to it, because silent failures are the real tax on automation.
3. Does doing it manually still teach me something?
Some tasks are sensors, not just work. Reading inbound inquiries manually taught me how the market talks about its problems — the exact language, the real objections, the patterns across industries. If I'd automated triage on day one, I'd have efficient routing and zero market intuition.
I automate a task only when the marginal learning from doing it manually has dropped close to zero. For lead intake, that took months. For invoice reconciliation, it took about two weeks. The timeline differs; the principle doesn't.
What automation actually bought me
Here's the honest accounting. Automation did not buy me leisure. It bought me attention — the ability to spend my thinking on the small number of decisions that actually move the needle, instead of spending it on coordination overhead.
The concrete wins, roughly in order of impact:
Follow-up cadences. The single highest-ROI automation I run. Not the first email — the second, third, and fourth touches that humans are terrible at sending consistently. Most of my business comes from people who didn't reply the first time. A system that reliably follows up, with judgment about when to stop, is worth more than almost anything else I run.
Listing and inventory sync. I market industrial listings across multiple surfaces. Keeping them in sync manually was a daily chore that I did badly — stale listings lingered, new ones were slow to appear. Automated sync turned a daily 30-minute task I resented into something I check for two minutes. The quality went up, not just the speed, because the machine doesn't get bored and skip the boring listings.
Invoice chasing. Nobody likes asking for money. A system that sends polite, escalating reminders on a schedule removed the emotional friction entirely. It also made me realize how much revenue was sitting in "I'll get to it" — which is embarrassing to admit but true.
Content pipelines. Research briefs, draft generation, scheduling — the mechanical parts of publishing. The judgment parts (what's worth saying, what's true) stay with me.
Notice what's not on the list: anything involving a new relationship, a price, or my name on something I haven't reviewed. Which brings me to the refusal list.
What I refuse to automate
This list is shorter but more important.
The send decision. Anything that goes out under my name to another human gets my explicit approval first. Every time. No exceptions, no "but it's been working fine for months." This is partly about quality and mostly about accountability. If my name is on it, I read it. The day I stop reading my own outbound is the day something embarrassing goes out and I have to explain that a machine did it. "A machine did it" is never an acceptable explanation when your name is on the line.
Pricing and negotiation. I've watched founders try to automate quoting and lived to regret the stories. Price is a judgment call that depends on context no system fully has: the relationship, the timing, what you know about the other party's constraints. Automating it doesn't just risk leaving money on the table — it risks signaling that you don't take the deal seriously enough to think about it.
First contact with anyone who matters. Templates are fine for the tenth follow-up. The first message to a potential partner, client, or hire gets written by me, specifically for them. People can smell automation in first contact, and the smell says "you're one of many." Sometimes you are one of many, and that's fine — but the people who matter deserve the signal that they aren't.
Anything I can't explain. If I can't describe in plain language what the automation does, when it runs, and what happens when it breaks, it doesn't go live. This rule sounds obvious. It's the one I break most often, usually at 11pm when something "just needs to work." Every one of those has come back to bite me.
The failure modes (mine, personally)
I've earned every lesson below the hard way.
Automating a broken process. My first serious automation took a messy manual workflow and made it run fast. The workflow was bad — inconsistent steps, unclear ownership, steps that existed for historical reasons. Automating it didn't fix it; it institutionalized it. The bad process now ran at machine speed, producing bad outcomes faster and with more confidence. Rule: if the manual process is embarrassing, fix the process first. Automation multiplies whatever you feed it, including dysfunction.
Silent breakage. The worst failure I ever had wasn't dramatic. A sync job quietly stopped picking up new items. Nothing errored. No alert fired. I discovered it weeks later when someone asked why a listing wasn't live. The system had been confidently doing nothing, and every surface looked healthy because "no errors" isn't the same as "working." Now every automation I run has a heartbeat — some positive signal that it did its job, not just the absence of an error. Silence is not success. This is the most expensive lesson on this list.
The monitoring tax. Here's the paradox nobody mentions: every automation you add creates a monitoring obligation. Ten automations means ten things that can break silently. At some point the monitoring overhead eats the time the automation saved. I hit this wall and had to consolidate — fewer, more robust automations with real health checks, instead of a sprawling collection of clever scripts I was afraid to touch. If you're spending more time babysitting your automations than the manual work took, you've built yourself a worse job.
Automating before the process works. Related to the broken-process problem but distinct: sometimes the process isn't broken, it's just unfinished. You're still figuring out the right steps. Automating at this stage freezes the process prematurely — you stop learning because the machine is doing it, and the process never gets good. My dozen-repetitions rule exists specifically to prevent this.
The weekly review: the backstop for all of it
None of the above works without a forcing function that makes me look at the whole machine regularly. Mine is a weekly review — same time, non-negotiable — where I look at every automation's output and ask three questions:
- Did it do what it was supposed to do this week?
- Did anything look weird, even if it technically worked?
- Is there something I'm still doing manually that passed the three-question filter?
Question two is the important one. "Technically worked but looked weird" is where silent failures announce themselves early, if you're listening. A follow-up sequence that sent but got zero replies for the first time. A sync that ran but processed half the usual volume. These are the tremors before the earthquake.
The review takes about an hour. It's the highest-leverage hour of my week, because it's the hour that keeps all the other automated hours honest.
What I'd tell a founder starting from zero
If you're running solo and thinking about automation, here's the sequence I'd actually recommend:
First, do everything manually for a while. Not forever — long enough to learn the shape of the work. You'll hate parts of it. Good. The hated parts are telling you where the leverage is, and the manual period is teaching you the judgment you'll need to encode later.
Second, automate the follow-up before anything else. Whatever your business, there's a version of "the thing humans forget to do consistently." That's your highest-ROI automation. It's boring, it's unglamorous, and it will pay for everything else.
Third, build the heartbeat before you build the automation. Decide how you'll know it's working before you turn it on. If you can't answer "how will I know this broke?", you're not ready to automate it.
Fourth, keep a refusal list. Write down what you'll never automate, and why. Revisit it yearly — the list should shrink slowly as tooling improves, but it should never be empty. The day your refusal list is empty is the day you've outsourced your judgment, and judgment is the whole business.
Fifth, do the weekly review. All of this decays without it. An hour a week to look at the machine. Non-negotiable.
The honest bottom line
Automation didn't make my businesses run themselves. It made them runnable by one person — which is a different, more honest claim. I still work full weeks. I still make every important decision personally. What changed is that my time goes to decisions and relationships instead of coordination and repetition.
The founders who get automation wrong usually make one of two mistakes: they automate too little and drown in busywork, or they automate too much and lose touch with their own business. The first mistake is visible and self-correcting — you feel the pain. The second is silent, which makes it more dangerous. A founder who has automated away all contact with customers, numbers, and operations isn't leveraged. They're absent.
I automate aggressively and refuse selectively. The filter is three questions, the backstop is a weekly review, and the rule that overrides everything is: if my name is on it, I read it first. Everything else is negotiable. That isn't.
