Antenor Blog 5 min read
Process Automation: Build vs Buy in 2026
A decision framework for AI process automation: when off-the-shelf tools win, when custom is cheaper over three years, and the integration test that settles it.
Buy when your process is standard, your systems are mainstream SaaS, and a vendor’s model of the workflow matches yours. Build when the process is your differentiator, when it spans systems no connector covers, or when per-seat and per-task pricing compounds past the cost of owning the automation. The test that settles most cases is integration depth: count the systems the workflow touches and the exceptions it must survive. Low-code tools win the shallow half of that map and lose the deep half, and the expensive mistake is forcing one side’s tool onto the other side’s problem.
The build versus buy question in process automation is older than the current AI wave, but LLMs changed both sides of it. Off-the-shelf tools became genuinely more capable: document extraction, email triage, and drafting tasks that required custom ML five years ago are now features. And custom builds became dramatically cheaper: an integration plus reasoning layer that once needed a team and a quarter can often be shipped by a small senior team in weeks. Both sides improved, so the boundary moved, and it is worth re-deriving rather than recycling a 2021 opinion.
What “buy” really buys you
Modern automation platforms, RPA suites, and the growing catalog of AI agent products are strongest when:
- The process is commodity. Invoice capture, ticket routing, standard approvals. Vendors have seen thousands of instances of it and their product encodes that experience.
- Your systems are mainstream. If everything lives in major SaaS products with supported connectors, integration cost approaches zero.
- Volume is modest and stable. Per-task or per-seat pricing is fine at low volume.
- You need it running this month. Time to first value is the honest headline advantage.
The costs arrive later and are structural: pricing that scales with your success, workflows bent to fit the vendor’s model of the process rather than yours, exception handling that dead-ends in “a human does it in the app,” and a dependency you do not control on a roadmap you do not set.
What “build” is actually for
Custom automation earns its cost in a different territory:
- The process is your edge. If the workflow embodies how you outcompete peers, renting the median version of it is strategically backwards.
- Deep or unusual integrations. Legacy ERPs, government and tax systems, bank interfaces, industry-specific platforms. Connector catalogs end exactly where these begin.
- End-to-end scope. Automating a full financial cycle rather than one task inside it. We have built this class of system: end-to-end finance automation covering electronic invoicing with connections to state tax systems, high-volume service billing, automatic commission settlement, bank expense consolidation, collections, stakeholder profit distribution, and monthly closes, for clients including a US regional telecom operator. No product covers that span; products cover islands inside it.
- Volume economics. At high volume, per-task pricing crosses over the fully loaded cost of owning the system, usually well inside a three-year horizon.
The costs are equally structural: you own uptime, monitoring, and change management when upstream systems shift. A custom build without an operations plan is a liability with good intentions.
The decision table
| Dimension | Favors buy | Favors build |
|---|---|---|
| Process type | Commodity, vendor-shaped | Differentiating, company-shaped |
| Systems touched | 1-2, mainstream SaaS with connectors | 3+, or legacy, or regulated interfaces |
| Exception rate | Low, humans handle leftovers in-app | High, exceptions are the process |
| Volume trajectory | Modest, flat | High or compounding |
| 3-year cost curve | Subscription stays below build cost | Per-task fees cross over ownership cost |
| Data sensitivity | Fine in vendor cloud | Must stay in your perimeter |
| Time pressure | Value needed in weeks | Payback measured in years, not weeks |
Score your workflow honestly across all seven rows. Mixed results are normal and usually mean: buy the shallow segments, build the connective tissue that makes them one process.
The failure modes on each side
Buying a build-shaped problem produces the automation graveyard: a licensed platform, three consultants, eighteen months, and a workflow that still ends in a spreadsheet because the real process had exceptions the tool could not express. The subscription continues either way.
Building a buy-shaped problem produces the artisanal invoice parser: six months of engineering to replicate, slightly worse, something available off the shelf, followed by years of maintenance nobody budgeted. Senior engineering judgment is knowing when not to build.
The 2026-specific failure is the agent demo trap: an LLM agent that completes the happy path impressively in a demo and collapses on real exception density. Agentic automation is real, but production readiness is defined by the worst ten percent of cases, not the best ninety. Whatever you build or buy, insist on seeing exception handling before believing anything else.
How we run this decision with clients
Our sequence is deliberately boring: map the process as it actually runs, including the exceptions people handle by habit and do not mention; count integration surfaces; price the buy option over three years at realistic volumes; price the build option fully loaded, including operations; then decide per segment, not per slogan. The output is a roadmap with a success metric agreed before any code, which is how all our process automation and AI agent work is scoped.
Frequently asked questions
Is low-code a middle path between build and buy?
For shallow workflows, yes, and it is often the right first move. The ceiling arrives at integration depth and exception complexity: when flows need custom code blocks to survive reality, you are building anyway, but inside a platform’s constraints and pricing. Treat low-code as “buy” in this framework and score it the same way.
How do LLM agents change the equation?
They compress the cost of the reasoning layer, which used to be the expensive part of custom automation, so “build” now competes at workflow sizes where it previously lost. They do not compress integration cost, exception design, or operations, which is where the real effort was all along. Vendors get the same capability lift, so the boundary moves but does not disappear.
What does a custom automation project cost?
It depends on integration count and exception complexity more than any other variable, which is why generic figures mislead. A scoping exercise that maps the process and its systems produces a real estimate quickly, and if the honest answer is “buy a product,” a good consultancy should say so and walk away from the build.