Do It Twice, Think About Automating; Three Times, Automate

Most people automate the wrong things. They build an elaborate workflow for a task they run twice a year, then keep doing the thing that eats two hours every morning by hand. The problem isn't a lack of tools. It's a lack of a rule for choosing.

So here's mine, and it's the one I actually live by: If I do something twice, I think about automating it. If three times — I automate it. That single sentence has decided more of my time allocation than any productivity system I've tried. Here is how it works and why it holds up.

Why three times is the line, not one

The instinct when you discover automation is to automate everything. That instinct is expensive. The first time you do a task, you don't yet know what it really is. You think you do. You don't. Almost every "simple, repeatable" task turns out to have exceptions, edge cases, and small judgment calls that only reveal themselves once you do the work by hand.

If you automate on the first pass, you encode your guesses. You build a clean pipeline around a task you've never actually understood, then spend the next month patching it as reality leaks in. That's not leverage. That's a second job maintaining a thing that was supposed to save you time.

The second time you do the task, you start to see the pattern. You notice which parts are mechanical and which parts need a human. That's the think step — you're not building yet, you're observing. By the third time, the shape of the work is clear. You know the inputs, the exceptions, the failure modes. Now what you build survives contact with reality, because it's modeled on reality instead of on your first-day assumptions.

Three times is also a frequency signal. If a task has come up three times in a reasonable window, it's almost certainly coming up a fourth, fifth, tenth time. You've crossed from "this happened" to "this happens." Automation only pays back across repetitions, so you want proof of repetition before you spend the build cost. Two data points is a coincidence. Three is a trend.

The math behind the rule

Strip away the philosophy and this is just a payback calculation. Automating a task costs you something up front — call it the build cost. It saves you something every time the task recurs — the friction you remove. You automate when the saved friction, multiplied by how often the task repeats, beats the build cost.

That gives you two dials, and they're the only two that matter:

• Frequency — how often does this actually happen? Daily, weekly, three-times-and-counting?
• Friction — how much does each instance cost? Minutes, focus, error rate, the mental tax of remembering to do it at all.

A task that's high frequency and high friction is an obvious yes — automate it now. A task that's low frequency and low friction is an obvious no — leave it alone; you'll waste more time building than you'll ever recover. The "twice, then three times" rule is just a cheap proxy for measuring frequency before you've committed any build cost. You let the task prove its own frequency by recurring, and you let your two manual passes measure its real friction. Then you decide with data instead of enthusiasm.

This is why "automate everything" is bad advice. Most tasks sit in the low-frequency or low-friction corner. They feel automatable because the tooling is impressive, but the payback never arrives. The rule keeps you out of that trap by refusing to count a task as worth automating until it's repeated enough to earn it.

What this looks like in practice

Take something boring and real: pulling numbers from one system, formatting them, and sending a recurring update. The first time, you do it manually and it takes twenty minutes. Fine. The second time, you notice you're repeating the exact same steps, and you make a mental note — that's the think trigger. You might save a template or write down the steps, but you don't build the machine yet.

The third time, you build. And because you've now done it by hand twice, you know the parts that actually vary (the date range, the one client who needs a different breakdown) and the parts that never change (the formatting, the recipients, the structure). Your automation handles the constant 90% and flags the variable 10% for you. That's a durable build, because it's shaped by what you learned doing the work, not by what you imagined before you'd done it.

Now contrast that with a task you do once a quarter — say, preparing a specific board document. It's high friction. It hurts every time. But it's low frequency, and worse, it's high judgment: the content changes meaningfully each time. Automating it would cost more than four quarters of doing it by hand, and the result would be brittle. So you don't. You leave it manual and spend the automation budget on the daily grind instead. The rule isn't "automate the painful things." It's "automate the repetitive things," and pain only matters once frequency clears the bar.

If you want the specific high-leverage candidates I'd start with, I broke those down in the first high-leverage wins for solo founders and in a piece on workflow-automation patterns that actually save hours. The short version: start where frequency and friction are both high and judgment is low — data movement, recurring reports, routine replies, scheduling, reminders.

AI didn't change the rule — it lowered the bar

Here's what AI actually changed. It didn't change the decision method; it changed the build cost. Tasks that used to require a developer, an integration budget, and two weeks of work can now be wired together in an afternoon. That means the payback line moved. Things that weren't worth automating a few years ago — because the build cost exceeded any realistic saving — now clear the bar easily, because building got cheap.

That's the real opportunity, and it's why I keep saying this to the people I teach. In an interview in 2024 I put it this way: AI lets you return to the garage; it rewards capability and talent, not capital. You no longer need a big budget to remove your own repetitive work. A solo operator can now build automations that would have needed a team and a six-figure line item not long ago. The leverage that used to be reserved for the well-funded is available to anyone willing to learn the tools.

But — and this is the part people skip — cheaper building makes the choosing more important, not less. When automation is hard and expensive, the cost itself forces discipline; you only build what's clearly worth it. When automation is cheap, the discipline has to come from you. Suddenly you can automate anything, so you have to decide what's actually worth automating. Without a rule, "AI makes this easy" becomes "I built fourteen things, maintain all of them, and only two matter." The frequency-and-friction filter is what keeps cheap building from turning into expensive sprawl.

This is also where the hype gets in the way. The conversation is full of impressive demos that solve problems you don't have. I've written more bluntly about what most entrepreneurs get wrong about AI, but the core mistake is exactly this: chasing capability instead of utility. The rule pulls you back to utility. It doesn't ask "what's possible?" It asks "what do I keep doing that I shouldn't have to?"

Build, buy, or just leave it alone

Once a task clears the frequency bar, you still have three options, not one. Frequency tells you the task is worth removing. It doesn't tell you to build — it tells you to solve. And solving might mean buying.

If a reliable, off-the-shelf tool already does the job well, buy it. Your time is better spent on the work that's specific to you. Build your own automation only when the task is genuinely particular to how you operate and nothing on the market fits cleanly. The failure mode here is founders who build custom versions of things they could have bought for a small monthly fee — they've correctly identified a repetitive task and then chosen the most expensive way to remove it. I worked through that decision in detail in build vs. buy: when an SME should wire its own AI workflow. The summary: frequency decides whether to automate; friction and fit decide how.

And sometimes the right answer is to do neither — to leave the task manual on purpose. Low frequency, high judgment, or genuinely enjoyable work doesn't belong in a pipeline. Automating it would cost more than it saves, or strip out the human judgment that made the output good. Knowing when not to automate is half the value of having a rule. A rule that only ever says "yes" isn't a rule; it's a permission slip.

Where I'd start tomorrow

If you're drowning in manual work and you want one thing to do, it's this: for one week, keep a running list of every task you do more than once. Don't automate anything yet. Just count. At the end of the week, look for the tasks that hit three. Those — and only those — are your starting set.

Then sort that set by friction. The task that repeats most often and hurts most each time is your first build. Solve it: buy a tool if one fits, build a small automation if it doesn't. Ship it, use it for a week, fix what breaks. Then move to the next one. You'll get more leverage from automating the three tasks that genuinely repeat than from a month spent building clever machines for work that barely happens.

This is the same filter I hand the tens of thousands of entrepreneurs I teach through VADYM.AI and KIERUNEK.AI — practical automation, not hype. Most of them don't have an automation problem. They have a prioritization problem, and a counting rule fixes it before a single tool gets opened. Two times, you think. Three times, you build. Everything else, you leave alone — and that restraint is what makes the things you do build actually worth maintaining.

If you want to go from this rule to a concrete first project, the next step is building your first useful AI agent for a small business. Start with the task that hit three. Build that. Then count again.