Build vs Buy: Custom Automation or Off-the-Shelf Software

Buy when the process is standard, the vendor's model of the work matches yours, and the main thing you need is a system of record. Build when the process is the thing that makes you different, when it spans systems no single vendor covers, or when the work is judgment-heavy document and exception handling that packaged workflow tools only partly touch. Most large organizations end up doing both: they license the core platforms and build the connective automation that makes those platforms usable for how they actually operate.

The question that actually decides it is not "which is cheaper." It is who owns the fit problem. Buying moves fit risk onto your operations team, who will absorb the gap between the product's assumptions and your reality through workarounds, spreadsheets and manual re-keying. Building moves fit risk onto engineering, who must specify, build, and keep maintaining something. Both are real costs. The mistake we see most often is comparing a licence fee against a build estimate and ignoring the operational cost of the workarounds the licence quietly requires.

The third answer, which vendors and integrators both dislike, is don't automate this yet. We say it more often than you might expect, and there's a section on it below.

When a packaged product wins

Buy when most of the following hold:

• The process is regulated, standardized, or externally defined. Payroll, tax filing, general ledger, benefits administration. The rules come from outside your organization and change without your input. Vendors amortize that compliance work across every customer; you cannot.
• You need a system of record, not a system of work. If the deliverable is durable, auditable state — customers, invoices, tickets, employees — buy it. Building a system of record means owning schema migrations, backup, retention and audit for the rest of its life.
• Your process has no defensible difference. If a consultant could walk in and tell you your process looks like everyone else's, that is a buy signal. Uniqueness that came from historical accident rather than deliberate design is not worth encoding in custom code.
• The product's data model matches how you think. This is the single best predictor of a successful purchase. If your team has to mentally translate every screen into their own vocabulary, adoption will be poor regardless of feature list.
• Volume is low or unpredictable. Per-seat or per-transaction pricing is efficient at small scale. It becomes punishing at large scale — but that's a problem for later, and later may never arrive.
• You need it working in weeks. A configured product beats a build on time-to-first-value almost every time. If the business case depends on speed more than fit, buy.

When a custom build wins

• The process spans systems no vendor owns end to end. The work starts in an inbox, touches an ERP, needs a lookup in a legacy database, and ends in a spreadsheet someone emails. Every vendor covers one leg. The value is in the whole chain, and the chain is yours to build.
• The process is how you compete. Underwriting logic, pricing, clinical intake, complex order configuration, claims triage. If the rules encode institutional knowledge that took years to accumulate, a product will flatten it into something generic and you will lose the edge you were paying for.
• The work is document and exception heavy. Unstructured inputs — contracts, remittances, statements, correspondence — arrive in formats no two counterparties agree on. This is where document and data intelligence work tends to beat template-based capture products, because the hard part is the exception path, not the happy path.
• Volume is high and growing. When you multiply a per-transaction fee by a large and rising number, buying stops being the cheap option. Build economics improve with volume; licence economics degrade.
• The last two implementations failed. If you've bought twice and the team is still working around the product, the problem is fit, and a third product will not fix it.
• Change is constant. If your process changes several times a year, waiting in a vendor's roadmap queue for each change is untenable. Owning the code means changing it when the business changes.

The hidden costs of buying

Licence fees are the visible, negotiable, least interesting part. What actually runs up the bill:

• Seat sprawl. Per-seat pricing pushes you to restrict access, which pushes work into email and spreadsheets so unlicensed people can participate. You pay twice: once for seats, once in shadow process.
• Implementation and configuration. Often a multiple of year-one licence cost, frequently delivered by a partner rather than the vendor. Ask who does the work before you sign.
• Integration. The connectors in the demo handle the common case. The rest is your problem, and it's usually the larger half.
• Change requests. Once you're live, every process change becomes a ticket to a vendor whose priorities are set by their largest customers. You have influence proportional to your spend, which is to say, usually none.
• Process distortion. The most expensive and least tracked cost. Teams reshape how they work to fit the tool, then hire to cover the seams. This shows up in headcount, not in the software budget, so nobody attributes it to the purchase.
• Lock-in. Ask, before signing: can we export our data in a usable form, including history, attachments and audit trail? How long does export take? Does the contract guarantee it? If the answer is vague, price that vagueness in.
• Renewal leverage. Once the product holds your operational history, negotiating position at renewal is weak. Uplifts land at the worst possible moment.

The hidden costs of building

We build systems for a living, and we'd rather you go in clear-eyed than sign something you resent later.

• Specification is the real work. Most of the effort in a build is discovering what the process actually does, including the parts nobody documented and the exceptions handled by one person who's been there fifteen years. If you can't get access to that person, the build will be wrong.
• Maintenance never ends. Upstream systems change, APIs deprecate, formats drift, regulations move. Budget ongoing capacity from day one, not as a contingency.
• Key-person risk. Custom systems built by one person, undocumented, become liabilities the day that person leaves. Insist on documentation, tests, and more than one person who understands the system.
• Security and compliance are yours. Access control, encryption, audit logging, retention, incident response. With a vendor these come bundled — imperfectly, but bundled. Building means owning them, which is why we treat security as part of the build rather than a review at the end.
• Scope creep. "While we're in here" is how a focused build becomes an unowned platform. The discipline of shipping a narrow thing, proving it, and then extending is what keeps build costs honest.
• Opportunity cost. Engineering capacity spent on a build is capacity not spent elsewhere. If your team is already stretched, that's a genuine argument for buying, independent of fit.

The hybrid that usually wins

In practice the strongest pattern is: buy the systems of record, build the systems of work. License the ERP, the CRM, the ticketing platform, the HR system. Then build the layer that moves work between them, applies your rules, handles the exceptions, and gives your team one place to act. That layer is where intelligent process automation earns its keep, and it's deliberately thin — it holds logic and orchestration, not durable records.

This keeps build scope small and replaceable. If you swap a vendor later, you rewrite an adapter rather than a business. It also avoids the worst outcome we see: heavy customization inside a purchased platform, which combines the cost of building with the lock-in of buying and blocks you from upgrading.

When the answer is "don't automate this yet"

Some processes should be left alone, and saying so early saves a lot of money.

• The process is about to change. A pending reorg, system migration, acquisition or regulatory change means you'd be automating something with a short remaining life. Wait.
• Nobody agrees on what the process is. If three people describe it three ways, automation will encode one version and break the other two. Standardize first, automate second.
• The process is broken, not slow. Automating a bad process produces bad outcomes faster and makes them harder to see. Fix the design first.
• The volume doesn't justify it. A task done a handful of times a month by someone who's good at it may simply not be worth the engineering, the maintenance, or the risk. Our value calculator is a quick way to sanity-check whether the numbers are there before anyone builds anything.
• The real bottleneck is upstream. If a downstream step is slow because inputs arrive late or incomplete, automating the downstream step moves the queue without shortening it.
• No one owns the outcome. Automation without an accountable owner degrades quietly. If you can't name the person whose numbers improve, don't start.

A decision checklist

Work through these before committing either way. Honest answers usually point clearly in one direction.

Question	Leans buy	Leans build
Who defines the rules?	Regulators or industry standards	Us, and they're a competitive asset
What are we producing?	A system of record	A system of work across existing records
How many systems does it touch?	One or two, with mature connectors	Several, including legacy or bespoke ones
How structured are the inputs?	Forms and clean data	Documents, email, mixed formats, exceptions
How often does the process change?	Rarely	Frequently, driven by our business
What happens at scale?	Volume is modest or flat	Volume is high and growing
How much configuration does the product need?	Light, within supported options	Heavy customization to be usable
What's our exit?	Clean, contracted data export	We own the code and the data
Who maintains it?	Vendor, with a support agreement	Named internal or partner team, funded

Two further tests. First, the workaround test: during a trial, count the workarounds your team invents. A handful is normal. If they're inventing one per screen, the fit isn't there. Second, the reversibility test: assume this decision is wrong and you learn that in a couple of years. Which option is cheaper to undo? Prefer the reversible one when the evidence is close.

How we approach it

We start with the process, not the technology: what triggers the work, who touches it, where it stalls, and what the exceptions actually are. That usually produces a clear split — the parts a product handles well, the parts that need building, and the parts that should be redesigned or retired before anyone automates them. We'll tell you when buying is the right call, including when the right call is a product we don't implement.

You can read more about how we work, see the range of our automation services, or look at case studies for how these decisions played out in practice. If the work is customer-facing, AI customer operations covers the build-versus-buy tradeoffs specific to contact and service workloads, where packaged tools are strong on channels and weak on your resolution logic.

If you're weighing a specific decision and want a second opinion from engineers who have no licence to sell you, talk to us. A short scoping conversation about one process is usually enough to tell you which way it goes.

Questions we get asked about this