$3 trillion — that is the estimated annual cost of process inefficiency in the global economy, per industry analysis. A significant portion lives inside organisations that built their own process automation tools and are quietly paying the maintenance cost. A smaller but growing portion lives inside organisations that bought enterprise automation platforms and are quietly paying the lock-in cost. The finance team has a question that neither vendor case study answers: which option costs less over 5 years?
This post builds that model. Neither option is universally correct — the right answer depends on process complexity, team stability, and a cost comparison that includes what most business cases leave out.
Why build goes wrong
Internal builds feel like the rational choice. Your team understands your processes better than any vendor. You control the roadmap. You avoid per-seat licensing. The initial cost is visible: developer time, infrastructure, scoping hours.
What is less visible at the time of the decision:
Maintenance drag. An internal process automation tool is a software product. It requires version updates, bug fixes, integration patches, and regression testing every time an upstream system changes. In banking operations, upstream systems change frequently — core banking upgrades, regulatory reporting changes, API version transitions. Each change is a maintenance event for every process automation that touches the affected system. If the team that built the tool has turned over, maintenance cost multiplies.
Knowledge concentration. Internal builds are often produced by 1 to 3 people who understand both the process and the technical implementation. When those people leave, the tool becomes an inherited liability. No one knows which rules are still valid, which were workarounds, and which can safely be changed. Extending the tool requires reverse-engineering it first.
Process drift. Business processes change. Compliance requirements change. A tool built against a 2023 process may enforce rules that are no longer accurate in 2026. Keeping the tool aligned with the actual process requires ongoing process discovery — a capability internal teams rarely maintain formally.
Hidden resourcing. Building looks like a one-time cost. It is not. Each enhancement request, each regulatory change, each upstream system update creates a new mini-project. These are rarely budgeted as ongoing maintenance — they surface as unplanned engineering demand competing with other priorities.
A plain statement of the pattern: every internal process automation tool is a hire you cannot fire. It has salary (maintenance cost), tenure (increasing complexity over time), and it does not resign when priorities shift.
Why buy goes wrong
Enterprise automation platforms solve the maintenance problem — updates are the vendor's responsibility. They introduce a different set of risks.
Licence creep. Per-seat licensing looks affordable at the point of purchase, when initial deployment covers one team. As the platform proves useful, demand expands. Each expansion adds licence cost. The rate negotiated at initial contract may not hold at renewal, particularly if the market has consolidated.
Configuration lock-in. Process automation platforms require configuration — workflow rules, integration mappings, approval logic. That configuration is written in the vendor's proprietary environment. When you want to switch vendors, the configuration does not transfer. You re-implement from scratch. The switching cost is a hidden ongoing cost: it functions as a retention mechanism that reduces your negotiating position at every renewal.
Capability overshoot. Enterprise platforms are priced for enterprise scale. An operations team automating 5 processes does not need the same infrastructure as one automating 500. Capability overshoot means paying for features and scale that are never used — a form of sunk cost that grows with each renewal.
Vendor dependency on process knowledge. Some platforms provide their own process discovery tooling. If you discover processes through the vendor's tool, the process models live in the vendor's environment. Switching vendors means losing the process documentation. This is not an accident of product design.
The 5-year TCO model
A fair comparison requires consistent cost categories across both options. Apply the following model to each.
Year 1 costs:
- Implementation (build: developer time + scoping; buy: licence + integration + professional services)
- Change management and training — typically underestimated in both options
- Opportunity cost of operations staff involved in rollout
Years 2–5 recurring costs:
- Maintenance (build: ongoing development; buy: ongoing licence + support tier)
- Enhancement requests — process changes, regulatory updates, upstream system changes
- Internal resourcing — the people managing the tool; build typically requires more
One-time future costs:
- Turnover recovery (build: reverse-engineering cost when builders leave; buy: re-configuration or migration if vendor relationship ends)
- Regulatory adaptation (both options incur this; build incurs it as development cost; buy incurs it as configuration cost plus potential professional-services fees)
The honest cost most models omit:
For build: the time value of the operations staff who are not improving processes because they are maintaining a tool. Every quarter the internal tool demands engineering attention is a quarter where new process improvements are not designed.
For buy: the exit cost. Model what it would cost to switch vendors in Year 3. If that number exceeds the cumulative licence savings, the platform is more expensive than it appears.
A decision threshold: if the difference between 5-year build and buy TCO is less than 30% of Year 1 implementation cost, do not decide on cost alone. Capability, flexibility, and vendor stability become the deciding factors.
When build is the better choice
Building internally is the right answer in specific, limited circumstances.
The process being automated is genuinely proprietary — its logic is a competitive differentiator, not a commodity operation that any bank runs. The organisation has a stable, senior technical team with process-domain expertise and a documented succession plan. The process is unlikely to change significantly over a 3-to-5-year horizon. Integration with proprietary internal systems is extensive enough that a vendor's integration layer would add more complexity than it removes.
Even in these cases, the build decision should include an explicit maintenance budget line — not just a build budget. If the maintenance budget is zero, the business case is incomplete.
When buy is the better choice
Buying from a specialist vendor makes more sense when:
- The process is a commodity operation — payments reconciliation, document validation, approval routing — where the vendor has already solved the hard problems.
- Internal technical capacity is limited or subject to turnover risk.
- Regulatory reporting requirements mean the process will change regularly, and vendor-managed updates are more reliable than in-house regulatory tracking.
- Time to deployment is a constraint.
The qualification that matters: buy from a vendor that makes the process model portable. If your process documentation lives inside the vendor's proprietary environment and cannot be exported in a usable format, you have accepted a form of lock-in that will raise your cost at every renewal.
E-S-S-A-M and the build-vs-buy decision
ESSAM applies the E-S-S-A-M framework — Eliminate, Simplify & Standardize, Automate, Migrate — before the automation investment decision is made. This sequence has direct implications for TCO.
Eliminate and Simplify & Standardize come before Automate. Automating a complex, rework-heavy process — whether with an internal build or a vendor platform — automates the complexity and rework at scale. Both options become more expensive and more brittle. Organisations that buy an enterprise automation platform before simplifying their processes typically spend 60 to 90 days re-engineering the process inside the platform — at vendor rates. This cost is almost never in the initial business case.
Automate should be applied to a process that is already clean. At that point, the build-vs-buy evaluation is simpler: the process is well-documented, the logic is stable, and the comparison is straightforward capability matching against a defined requirement.
Migrate — routing human judgment to the right people — is a step neither build nor buy eliminates. The question is which option makes migration more reliable and less expensive to maintain over time.
Evidence: the Kuwait bank and the design-before-build principle
A Kuwait bank's procurement process had accumulated approval stages and correction loops over years of incremental changes. Each addition seemed reasonable in isolation. The cumulative result was a process running at 139 days. Building or buying automation against that process would have automated 139 days of inefficiency at scale.
Abdulla Al-Awadi, then the Chief Strategy Officer, applied the ESSAM baseline first. The baseline exposed redundant approval stages and informal correction loops. The team eliminated and standardised before automating. The result: 139 days to 57 days — a 59% reduction, with 82 days retired entirely and a 106.9% efficiency improvement.
The automation investment (the A in E-S-S-A-M) was applied to a 57-day process, not a 139-day one. The TCO of the automation — build or buy — was materially lower as a result of the prior redesign.
This is a real case. It demonstrates a general principle: the cost of any automation option is directly proportional to the complexity of the process being automated. Simplify the process first, then make the investment decision.
The process complexity multiplier
One factor that makes both options more expensive is frequently omitted from pre-decision analysis: current process complexity.
A complex, rework-heavy process costs more to automate, maintain, and update than a clean, standardised one — regardless of whether it is built internally or deployed on a vendor platform. Every informal workaround, every undocumented exception route, and every residual approval stage must be handled in the automation logic. That logic requires maintenance. When the process changes, the maintenance is compounded.
Reducing process complexity before making the automation investment is the single change that most improves the 5-year TCO of either option. This is the practical argument for completing a process baseline and redesign — using the E-S-S-A-M framework — before committing to a build or buy decision. You are not adding a step; you are reducing the cost of every subsequent step.
Applying this to your decision
Before filling in the TCO model, answer these questions:
- Has this process been baselined — actual route, not system-recorded route?
- What is the current rework rate? A high rework rate makes both build and buy more expensive.
- What is the expected process stability over 5 years? Regulatory-adjacent processes change more frequently.
- Does the organisation have a credible maintenance budget — or is maintenance assumed to be zero after Year 1?
- What is the exit cost if the chosen option proves wrong in Year 3?
If questions 1 and 2 cannot be answered from current data, the TCO model will be built on assumptions. Assumptions produce business cases that look sound at approval and disappoint at the Year 2 review.
Honest limitations
This framework does not make the build-vs-buy decision. It makes the decision more honest by surfacing costs that are routinely omitted. Some organisations will find that their specific process logic, integration depth, and technical team stability make build the correct answer after thorough analysis. Others will find the inverse.
ESSAM is a buy option. This post is written from that position. The framework above is designed to be applied honestly — including in cases where build is the better choice after a complete cost model.
The TCO your CFO is waiting for
Your CFO has seen vendor ROI calculators. What they want is a model built on your process data — your rework rate, your volume, your maintenance assumptions.
Describe one process you are evaluating for automation to the ESSAM team. Include current volume, known rework rate if measured, and whether an internal build or vendor platform is the current leading option. ESSAM returns a process baseline, a waste map, and an initial cost model your CFO can interrogate. No vendor deck required — start at https://apac.essam.ai/contact.
Frequently asked questions
What is total cost of ownership (TCO) for process automation?
TCO for process automation includes all costs over the evaluation period: initial implementation, ongoing maintenance, enhancement requests, internal resourcing, regulatory adaptation, and exit costs. Most initial business cases capture only Year 1 implementation cost. The difference between Year 1 cost and 5-year TCO is where most build-vs-buy decisions go wrong.
What costs are most often missing from internal build estimates?
The most frequently omitted costs in internal build estimates are ongoing maintenance (patching, updates, integration fixes), turnover recovery (reverse-engineering the tool when the builder leaves), regulatory adaptation (updating logic when compliance requirements change), and the opportunity cost of engineering time spent maintaining the tool rather than building new capability.
What costs are most often missing from vendor platform estimates?
Common omissions in vendor platform estimates include licence growth as deployment expands beyond the initial team, professional-services costs for regulatory configuration changes, and exit cost — the re-implementation expense if the organisation wants to switch vendors. Configuration lock-in, where process models are stored in proprietary formats, is the mechanism that makes exit costs real but invisible at purchase.
When does building internally make more sense than buying?
Internal build is more competitive when the process being automated is genuinely proprietary (competitive-differentiating logic, not a commodity operation), when the organisation has a stable senior technical team with documented succession, when process change is unlikely over a 3-to-5-year horizon, and when integration depth with internal systems makes vendor integration layers add more complexity than they remove.
How does ESSAM fit into the build-vs-buy decision?
ESSAM provides the process baseline that makes either option less expensive. Automating a simplified, standardised process — whether internally built or vendor-deployed — costs less and performs better than automating a complex, rework-heavy one. ESSAM's pricing starts at $40/month. Full details are at the pricing page. The process baseline ESSAM produces is the prerequisite for any honest TCO model.
Related reading: