Should I buy an AI tool or build a custom automation?

The default should be buy. Building something a product already does well is an expensive way to end up with a worse version of it that you now have to maintain.

That default has exceptions, and they are worth knowing precisely, because getting this decision wrong in either direction is costly.

Buy when

• The process is standard. Email marketing, e-signatures, transcription, scheduling, payroll. Thousands of businesses do this identically and the products are mature.
• You need it this week. A subscription is live today. A build is not.
• The requirement is still moving. Renting is the cheaper way to be wrong.
• A product already covers most of it. Fighting a product for the last fifth is usually cheaper than building the whole thing.
• Support matters more than fit. Someone else carries the pager.
• It is a regulated function where the vendor takes on the burden of staying current. Let them.

We turn down build work on this basis regularly. If a £40 a month tool does what you need, that is what we will tell you.

Build when

• The value is in the difference. If your process is standard, buy it. If the way you do it is why clients choose you, a product that averages every customer’s workflow will erase exactly the thing that makes you good.
• The workflow crosses several systems. Products own their own boundaries. Nothing off the shelf knows how your CRM, your finance system and your operations spreadsheet relate to each other. You either build the connective layer or you keep paying people to be it.
• Per-seat pricing has stopped making sense. See the numbers below.
• You are paying for a tenth of a product. Common with enterprise platforms bought by growing SMEs. You are funding a feature set built for a company ten times your size.
• The product you need does not exist. Niche sectors get badly served, and the vertical tools that do exist are often dated, expensive and still a poor fit.
• You need the data somewhere else. If the output has to land in your systems in your shape, an integration is being built either way.

Custom build versus off-the-shelf software: the maths

This is the calculation most people never sit down and do.

Take a mid-priced business tool at £75 per user per month. The licence cost alone:

Users	Per year	Over five years
10	£9,000	£45,000
25	£22,500	£112,500
50	£45,000	£225,000

Now the other side. A comparable internal system sits inside our fixed-fee range, hosting for something at SME scale runs from tens to a few hundred pounds a month depending on volume, and ongoing development is optional rather than automatic. Critically, none of it scales with headcount. Adding your fiftieth user costs nothing.

At ten users, buying usually wins comfortably. Somewhere in the twenties it gets close. By fifty the build has typically paid for itself several times over, and you own the asset rather than renting it.

Two caveats against our own argument. That comparison assumes the off-the-shelf product needs no configuration or implementation work, and it nearly always does. It also assumes the custom system stays as simple as it started, and requirements have a habit of growing. Run the numbers with your own headcount and your own quotes before trusting anyone’s illustration, including this one.

The costs both sides forget

On the buy side: implementation and configuration, which can exceed a year of licence fees. Data migration. The integrations they charge extra for, or that need a middleware subscription on top. Price rises you do not control. And the staff time spent working around the parts that do not fit, which is real money that never appears on an invoice.

On the build side: maintenance is the real number. APIs change, platforms deprecate endpoints, and someone has to notice when a workflow silently stops firing at three in the morning. Then there is security work, access control and audit logging, which is not optional and takes proper time. And key person risk, if only one person understands how it works.

Anyone telling you one of these is cheap and the other is expensive is selling you something.

What has changed recently

The standard advice to buy rather than build comes from a world where a modest internal system meant a team of developers and six months. That was true, and it is much less true now.

The parts that used to consume a build budget, the boilerplate and the forms and the routine screens, are genuinely fast today. What still takes real time is the thinking: understanding your process properly, designing the data model so it survives contact with reality, and getting security right. The practical effect is that the break-even point has moved down. Builds that only made sense for a company of two hundred people can make sense for a company of twenty.

The obvious caveat is that faster building has also produced a great deal of bad software. Something assembled quickly with no data model, no access control and no tests will demo beautifully and fall over in production. The speed is real, and it only helps if someone competent is steering. If you last priced a custom build before 2024, though, your number is out of date.

The middle option

Most of what SMEs need sits between the two. A known automation pattern, tailored to your systems and your rules. That is what our ready-made automations are: proven patterns like document extraction, lead routing and CV matching, deployed and adapted to your setup rather than designed from a blank page. Faster and cheaper than a custom build, better fitted than a product.

The other version of the middle is what most of our clients end up with. Keep the accounting package, the email, the e-signature tool and the CRM if it broadly works. Build the layer across them that does the thing none of them do, whether that is a client portal, an operations console, or a pipeline that reconciles four sources into one report you actually trust. It is the cheapest route to the outcome people want, and it means you are never betting the business on a single build.

Five questions before you decide

1. Is the way we do this genuinely different from our competitors, or do we just think it is?
2. How many people will use it, and what will that number be in three years?
3. How many systems does the real process touch, start to finish?
4. Has the process been stable for at least six months?
5. If this software vanished tomorrow, what breaks?

Standard, small, single-system and still changing points to buying. Distinctive, growing, multi-system and settled points to building.

If you are still unsure, ask what happens if you do nothing for six months. If the answer is “we keep paying someone to do it manually”, price both options against that cost and pick the cheaper one. If the answer is “we lose deals”, weight speed heavily, buy something now, and build properly once you know what you actually need.