Before you build automation, check whether the workflow you are trying to automate already lives inside a tool that does most of the work natively. Plenty of teams pay for automation when an upgrade or a different SaaS would solve the same problem at a tenth of the cost.
There is a kind of conversation that happens roughly once a quarter. A founder describes a pain point, sketches the workflow, asks what an automation would cost. By the end of the call, the answer is usually that they do not need an automation at all. They need a tool they do not yet own, or a better version of one they already pay for.
Saying this out loud does not pay our bills. Saying it anyway is part of the work.
The pre-build check
Before scoping any automation build, run the workflow through a quick three-question check.
Does a tool you already pay for do this natively? Most modern SaaS includes more functionality than people use. The CRM you pay for might already have a workflow builder. The email platform might already segment dynamically. The spreadsheet you treat as a database might be a database now. Read the documentation for the tools you have before you build something on top of them.
Does a different tool in the same category do this natively? If your current CRM cannot route enquiries by score, the question is whether HubSpot’s basic tier can. Or Pipedrive’s. Or Zoho’s. Switching CRMs is rarely fun, but switching is sometimes cheaper than building, and the new tool generally comes with twenty other capabilities you did not have to commission.
Is there a category-specific tool you have not heard of yet? This is the harder question. There are now reservation platforms, intake portals, inventory tools, and dozens of other category-specific tools that did not exist three years ago. Some of them ship a workable version of the thing you were going to build, for the cost of a SaaS subscription.
When automation actually beats tooling
Automation wins, usually, when one of three things is true.
The workflow connects multiple systems. No single tool covers it because it spans your CRM, your email tool, your accounting system, and a folder in Google Drive. This is the common case in SMEs, and it is where automation earns its keep.
The logic is specific to your business. A standard tool implements a standard workflow. If yours has unusual rules, edge cases, or branching that would require constant manual override inside a generic tool, building the automation is often cleaner.
The volume is high enough to justify the build. A custom flow handling ten enquiries a day for the next year pays back. A custom flow handling ten enquiries a week probably does not.
When tools beat automation
Tools win when the problem stays inside one stage of one process. Booking software handles bookings. CRM software handles pipeline. Accounting software handles accounts. If the work fits cleanly inside one of those, the right move is almost always to use the right tool well before building anything around it.
Tools also win when the problem is changing. A custom build is a snapshot of how things work today. If your process is going to look different in three months, the snapshot will be obsolete and the custom code will be the thing you regret. A standard tool that gets quarterly updates will move with you.
The honest version of the question
The honest version of the question we ask in audit calls is: what would happen if you did nothing, kept the workflow exactly as it is today, and gave the team a better tool to do it inside?
If the answer is “the problem mostly goes away”, then better tooling is the answer.
If the answer is “the team would still spend half their week on this”, then automation is the answer.
The conversation gets a lot shorter once that question is on the table.