The question is normally posed as two options, and there are three. Between buying finished software and commissioning a custom system sits the option most companies actually take: assembling something on a platform, with internal people owning it. It has a distinct cost profile from either neighbour and it is where a large share of automation projects quietly succeed and quietly fail.

It is also worth saying plainly that this page is published by a company that builds custom agents. The test below is written so that it returns “buy” when buying is right, because a test that always returns “build” is not a test.

The three options

Buy: finished software
A product that already does the thing — an AI helpdesk, a meeting notetaker, a document extraction tool. You configure it. Fast, priced per seat or per volume, and the vendor carries the maintenance. You get their idea of the process.
Assemble: a platform build
An automation platform, a model API, and someone internal wiring them together. Cheap to start, genuinely flexible, and the option most likely to be underestimated — the wiring is a system, and systems need an owner.
Build: a custom agent
Built for your specific process, against your specific systems, with the accuracy and escalation requirements your work actually has. Highest upfront cost, and the only option that fits a process you cannot change.

When buying is clearly right

Buy when the process you are automating is not distinctive. If your problem is one that thousands of companies have in almost the same shape, someone has already built a better version of it than a bespoke project will produce, and they are spreading the cost of maintaining it across all of those customers.

  • Meeting transcription and summaries. Nobody has a proprietary way of taking minutes.
  • General-purpose writing and research assistance for individuals.
  • Standard helpdesk deflection on a standard helpdesk, where the vendor already integrates with the tool you use.
  • Anything where your requirement is genuinely “the industry default, working, this month”.

The trap on this side is not the licence fee. It is discovering that the product does ninety per cent of your process and that the last ten per cent is the part that mattered — at which point you are running a manual workaround around a tool you are paying for, which is a worse position than either alternative.

When building is clearly right

Build when the process is yours in a way that matters commercially, or when it touches systems no product will ever integrate with.

  • The workflow is a competitive advantage. If how you handle this is part of why customers choose you, configuring somebody else’s idea of it is a downgrade.
  • It spans systems that have no common product. Your ERP, a supplier portal and an internal tool written years ago will not appear together in any vendor’s integration list.
  • The accuracy or escalation requirements are unusual. Off-the-shelf tools ship with a default tolerance for being wrong, and it is rarely adjustable to a stricter one.
  • The volume is high enough that per-seat or per-task pricing has become the dominant cost, and optimisation would pay for itself.

That last one is worth watching for, because it arrives gradually. A tool that was excellent value at twenty users is a line item worth examining at four hundred, and the calculation that justified buying is rarely revisited.

The cost each side does not quote you

Buying: the integration tax and the exit
The subscription is the visible number. The invisible ones are getting your data in and out, the workarounds for the parts it does not do, and what happens when the vendor changes their pricing or their roadmap. Your process is now shaped around a product you do not control.
Assembling: the owner nobody assigned
Platform builds are cheap because the labour is someone’s spare capacity. That works until the person who built it changes role. Then you have an undocumented production dependency and nobody who knows why it does what it does. This is the most common way an internal automation dies, and it dies silently.
Building: the maintenance you now own
A custom agent matches your process as it was when it was built. Processes move — a form gains two fields, a supplier changes format, the team changes how they triage. A custom build without a maintenance arrangement decays, and it decays while appearing to work.

A test that works

Answer these in order. The first “yes” is your answer.

  1. Is there a product that does this, and would we be content to run the process the way the product runs it? Buy. Do not build a worse version of an existing product for the pleasure of owning it.
  2. Is the process contested internally, or about to change? Do neither yet. Automating a disputed or short-lived process is the reliable way to spend a build budget on nothing.
  3. Does it touch systems no vendor will integrate with, or carry accuracy requirements no product exposes? Build. This is the case custom work exists for.
  4. Is it small, low-risk, and would one capable internal person enjoy owning it? Assemble — and name the owner in writing, because that is the step that is always skipped.

Question two is the one worth pausing on. A surprising number of build-or-buy conversations are premature: the underlying process has not been settled, and no purchasing decision fixes that. Establishing what the process actually is, and what it costs today, is cheap relative to either option and changes the answer often enough to be worth doing first.

The answer most companies land on

Buy the commodity, build the differentiator. Use finished products for transcription, general assistance and standard support deflection, and build custom where the process is genuinely yours. This is not a compromise position — it is the correct allocation, and it is what a sensible portfolio looks like after two or three years.

The failure mode is doing the reverse: buying a product for the distinctive process because it was faster, and building bespoke tooling for the commodity one because someone found it interesting. Both mistakes are common, and both are visible in advance if the question is asked process by process rather than once for the whole company.

Buy where you are ordinary. Build where you are not. The mistake is not knowing which you are.