Whether to automate a process, buy software for it, or hire someone comes down to three things, checked in this order: how often it happens, what it costs you a year, and how much judgment the work requires. Get the order right and the rest is arithmetic.
Almost every article on this topic is written by someone who sells automation, and it ends with “automate it.” I build automations for a living, and that’s not where this one ends.
The three-test filter
Before you consider a specific tool or a specific hire, run the process through three tests. Fail any one of them and the honest answer is “not yet.”
First: does the pain recur weekly? Not monthly, not “sometimes when things get busy.” A process that surfaces every week is one your team has built habits around — habits that are annoying to interrupt but cheap to fix once, because the fix pays out every single week afterward. A process that shows up twice a quarter doesn’t justify the setup cost of automation or the overhead of new software, no matter how irritating it is when it happens.
Second: does it cost $10,000 or more a year, counted honestly — hours spent at a fully loaded rate, plus errors, plus the work that doesn’t get done because someone is stuck doing this instead? Below that threshold, the math on most automation projects and software subscriptions doesn’t clear the setup and switching cost inside a reasonable payback window. Above it, you can afford to be wrong once and still come out ahead.
Third: is there a budget owner who can approve a pilot within 30 days? If the answer requires talking your partner into it and waiting for next quarter’s cash flow to loosen up, the process may be real and the cost may be real, but the organization isn’t ready to act on either one yet, and starting a project nobody can approve wastes more time than the original problem did.
Pass all three and you’ve earned the right to ask which of the next three sections applies to you. Fail one, and the honest move is to wait or fix the underlying process first — which is its own section below, and the one that trips up the most people.
When buying software wins
I’ll say plainly what most vendors won’t: most processes that clear the three-test filter should end with buying software, not building anything. If the pain you’re describing is common — expense approvals, appointment scheduling, invoice matching, e-signatures — somebody has already built a product for it, priced to spread across many customers, with the edge cases fixed that you haven’t hit yet. Your version of the problem is rarely as unique as it feels from the inside.
I say this knowing it costs me work. A five-person company burning ten hours a week on expense reports should buy a $30-a-seat expense tool this month, not commission anything custom. The build would take longer than the vendor’s onboarding and still lack the receipt scanning, currency handling, and audit trail the vendor has spent years hardening.
The tell that you’re in this category: describe the process to someone outside your business and they immediately name two or three products that do it — the market already solved this, and building it yourself is paying for reinvention, not innovation.
When automating wins
Automating — building or configuring something specific to your process, rather than buying a general tool — wins when the process is stable, happens often, and doesn’t map cleanly onto anything a vendor sells.
“Stable” matters more than people expect. If the steps change every few months because your business is still figuring out how it wants to operate, you’ll be rebuilding the automation as often as the process changes, and that cost never stops. “High-frequency” is the weekly threshold from the filter — automation earns back its setup cost through repetition, and repetition is the only thing that pays it back.
The “doesn’t fit a product” part is where judgment comes in. If you’ve genuinely shopped — not just assumed — and every option forces you to change how you operate to fit the software, that’s a real signal. A process that moves data between two systems that don’t talk to each other, in a sequence specific to how your business actually runs, is a good candidate. I wrote more on that exact pattern — the cost of retyping the same information into two systems by hand — in a companion piece on why manual double-entry is more expensive than it looks.
Sometimes the fit is less a script and more a set of connected rules — pulling data from unstructured input like emails or documents, applying logic, and routing the result. That end of the work is covered on my AI services and workflow automation page.
When hiring a person wins
This is the section a lot of people selling automation skip, and it’s the most important one here.
Judgment-heavy, exception-heavy, relationship-heavy, or genuinely low-volume work is often best handled by a person, and no framework should talk you out of that.
Here’s a concrete case. Say you run a small property management company and you handle vendor disputes — a contractor’s invoice doesn’t match the work order, a tenant disputes a repair charge, a vendor wants a rush payment outside normal terms. This happens maybe six or eight times a month. Each one is different: different vendor, different relationship, different history, different amount that matters or doesn’t depending on who’s asking. There’s no pattern to automate because the whole job is handling the exception, and there’s no software to buy because the product would just be a form for typing in the decision you were already about to make.
Six to eight events a month fails the frequency test outright — it isn’t weekly. Even if it somehow cleared $10,000 a year in owner time, and even if budget were approved tomorrow, automating or buying software for it would put a rigid tool between you and decisions that need a person weighing context every time. The right move is to hire a part-time bookkeeper or operations person who can own vendor relationships and use judgment call by call. Don’t build a workflow for this. Don’t buy a platform for it either. Hire someone — or, if the volume is genuinely this low, keep doing it yourself.
I’ll say that plainly because it’s true, and because a framework that never tells you to walk away from software and services isn’t a framework — it’s a sales pitch wearing one.
The build-versus-buy trap
Even after the three tests point toward “build something,” run one more number before you commit: the three-year cost of building versus the three-year cost of a subscription, including the maintenance people forget to count.
Say a developer quotes $35,000 to build a custom tool that replaces a manual process for a 10-person team. That number usually gets compared against a subscription’s sticker price and nothing else, which is the trap. Custom software needs upkeep — security patches, breakage when a connected system changes, the small feature requests that pile up. A reasonable rule of thumb is 15–20% of the build cost per year in ongoing maintenance; call it 20% here, or $7,000 a year. Over three years that’s $21,000 in maintenance on top of the $35,000 build.
Now the subscription. A per-seat tool at $40 a month for 10 seats is $400 a month, or $4,800 a year, with no maintenance line, because that cost sits with the vendor and gets spread across every customer they have.
- Custom build: $35,000 upfront + $21,000 maintenance over three years (20% of build cost per year) = $56,000 total
- Per-seat subscription: $400 a month × 36 months = $14,400 total
- Three-year difference: $41,600, almost entirely explained by the maintenance line the build quote left out
Change the seat count, the build quote, or the maintenance percentage and the specific numbers move — but run this comparison honestly, with a real maintenance line, before any custom build gets approved. Skipping the maintenance number is how build-versus-buy decisions get made wrong even when the frequency and cost thresholds were passed correctly.
Where people get this wrong
The single most expensive mistake in this entire decision isn’t picking automate when you should have bought, or buying when you should have hired. It’s automating a process that was already broken.
A process with unclear ownership, missing approval steps, or steps people quietly skip doesn’t get better when you wrap software around it — it gets worse, faster, and at a larger scale. Automation and most software do exactly what you tell them to do, which means every flaw in the process now runs without anyone noticing, instead of being caught by the employee who used to spot it and fix it by hand. I’ve watched a broken approval chain go from an annoying weekly delay to a real financial exposure within a month of being automated, because nobody was still reading each transaction before it went through.
Fix the process first. Map the actual steps, not the ones in the training document nobody follows. Decide who owns each step and what happens on an exception. Only once the process itself is sound does it make sense to ask whether to automate it, buy something for it, or staff it — which is the same mapping work covered on my business process improvement page, and it’s worth doing regardless of what you decide.
Frequently asked questions
A few questions I get once someone has run their own process through the three-test filter.
What’s the cheapest place to start?
Run the three-test filter yourself before spending anything: does the pain hit weekly, does it cost $10,000 or more a year, and can someone approve a pilot within 30 days? That costs nothing. If it passes, the cheapest paid step is usually shopping for existing software before considering any custom build.
How do I tell if a process can be automated at all?
Write down the steps exactly as they happen today, including the exceptions people handle from memory. If most instances follow the same steps in the same order, it’s a candidate. If every instance needs someone to weigh context and decide, that’s judgment work, and judgment work usually means hiring, not automating.
Should we build custom or buy off the shelf?
Buy first, by default. Building only makes sense when the process is stable, happens weekly or more, and no existing product fits without forcing you to change how you operate. Even then, compare three-year costs including maintenance, not just an upfront build quote against a subscription’s sticker price.
What if we pick wrong?
Most wrong picks are recoverable — you cancel a subscription, or route around a workflow that didn’t help. The genuinely expensive mistakes are a long contract you can’t exit or a custom build nobody can maintain once the person who built it moves on. Favor reversible choices while you’re still learning.
If you’re not sure which of the three answers applies to your situation, that’s what the Business Automation Audit is for. It’s $1,500 flat, takes two weeks, and the deliverable is a written roadmap: your processes mapped, each one ranked by what it actually costs you per year, with a recommended fix and an effort estimate for each. If you move forward with implementation afterward, the audit fee is credited toward the work. It covers one business, up to about five processes.
Sometimes the audit comes back recommending exactly what you’d expect — a specific automation, scoped with an effort estimate. Other times it comes back saying buy the $40-a-month product that already does this, or hire a part-time person for the one process that’s really a judgment problem, not a technology problem. That’s the same three-test logic in this post, applied to your own processes. Details and current rates are on the pricing page.