Build, Buy, or Configure: Choosing How to Automate a Process

Choose build when the process is a genuine source of competitive advantage and no platform models it well; choose buy when a mature vendor already solves 80% of the problem; choose configure when a workflow platform can model your logic without custom code. In practice, total cost of ownership (TCO) and long-run maintenance burden — not the initial build estimate — should drive the decision.

Quick answer: Default to configuring a platform. Reserve custom builds for processes that are genuinely core to your competitive advantage, and buy outright when a vendor's off-the-shelf process already matches your needs closely enough that customization would only slow you down.

Why "Build vs. Buy" Is the Wrong Question

The framing itself misleads teams into a binary that doesn't match how automation decisions actually play out. Most enterprise processes sit on a spectrum between fully custom code and a fully packaged SaaS tool, with configuration as the underused middle option. Naming that middle option changes the whole analysis.

Configuration means using a workflow, RPA, or business-process-automation platform's native building blocks — forms, rules, connectors, approval chains — to model your process without writing bespoke application code. It's not "buy" because you're still designing the logic yourself. It's not "build" because you're not maintaining a codebase, a deployment pipeline, or a runtime.

Enterprise and platform PMs tend to reach for "build" reflexively, especially when engineering has bandwidth and a clear technical vision. That instinct ignores two things: how process requirements evolve, and how maintenance cost compounds. A BPMN map of the process usually reveals that only a few steps are actually novel — the rest are variations on approval routing, data validation, and notification patterns that platforms have solved thousands of times.

Simon Wardley's Wardley Mapping technique offers a useful lens here: as a capability moves from "genesis" (novel, custom) toward "commodity" (standardized, widely available), the rational choice shifts from build toward buy or configure. Most workflow steps — routing a request, escalating an approval, syncing a record — are already commodity-grade capability, even if your specific business rules are not.

The Real Cost Curve

Build costs look attractive at the estimation stage because they're front-loaded and visible: a sprint plan, a headcount allocation, a delivery date. What's invisible at that stage is the tail — the multi-year cost of patching, upgrading dependencies, onboarding new engineers to a bespoke system, and re-testing every change against edge cases nobody documented.

Gartner's Pace-Layered Application Strategy captures this trade-off well: it categorizes systems as "systems of record" (stable, rarely change — good buy candidates), "systems of differentiation" (change often, competitive — good configure/build candidates), and "systems of innovation" (short-lived, experimental — build fast, throw away). Sorting your process into the right layer before choosing a path prevents over-investing in stability where you need speed, or vice versa.

The Fit, TCO, Lock-In, Differentiation Matrix

A structured criteria matrix beats gut-feel because it forces you to weigh factors that pull in opposite directions — a process can score well on fit and terribly on lock-in, and no single number captures that tension. Score each candidate process on four dimensions, then read the pattern rather than a total.

How to Score Each Dimension

1. Fit — How closely does an off-the-shelf or configurable pattern match your actual process, without heavy workarounds? Score 1 (no match) to 5 (near-perfect match).
2. TCO — Estimate 3-year cost including licenses, maintenance engineering hours, upgrade cycles, and opportunity cost of engineering time diverted elsewhere. Score 1 (very high) to 5 (very low).
3. Lock-in — How hard would it be to migrate off this choice in 2-3 years if the vendor, platform, or architecture stops serving you? Score 1 (severe lock-in) to 5 (easy exit).
4. Differentiation — Does doing this process well (or uniquely) create a defensible advantage for your business, or is it table-stakes plumbing? Score 1 (pure differentiator, must control) to 5 (pure commodity, don't bother controlling).

Notice that the matrix doesn't produce a single "winner" score — it produces a pattern. High fit and low differentiation almost always means buy or configure. Low fit and high differentiation almost always means build. The ambiguous middle — moderate fit, moderate differentiation — is where most enterprise debates actually live, and where the "is this core?" test below does the real work.

The "Is This Core to Our Advantage?" Test

This test cuts through matrix ambiguity by asking a single, sharper question: if a competitor automated this process identically to us, would customers notice or care? If the honest answer is no, building it yourself is usually wasted engineering effort. Nicholas Carr's influential Harvard Business Review argument that "IT doesn't matter" made a version of this point at the infrastructure level two decades ago — commodity capability rarely deserves custom investment, no matter how tempting it is to control everything.

Ask these three questions about the process before writing a line of code:

• Does the logic embed proprietary knowledge? A pricing algorithm built on years of proprietary data is different from a standard three-tier approval chain.
• Does speed of iteration matter more than stability? If you expect to change the rules weekly as you learn, a rigid custom build fights you; a configurable platform or even a simple rules engine (see the guidance on choosing rules vs. RPA vs. an agent per step) adapts faster.
• Would losing control of this process hurt your competitive position? If a vendor changing their roadmap would meaningfully damage your business, that's a build signal — but be honest about how likely that scenario really is versus how much it flatters engineering's roadmap.

Joel Spolsky's classic essay on "Not Invented Here" syndrome is worth revisiting here: he argued teams should build only what's genuinely differentiating and should feel no shame borrowing infrastructure, libraries, or platforms for everything else. The same logic applies cleanly to process automation — a workflow engine is infrastructure, not differentiation, in the overwhelming majority of enterprise cases.

Most processes that feel differentiating on the surface are actually generic processes wrapped around one or two genuinely proprietary decision points. Isolate the proprietary part; configure or buy the wrapper around it.

When Configuration Beats Both Build and Buy

Configuration wins when your process has enough business-specific nuance to defeat an out-of-the-box SaaS tool, but not enough novelty to justify a custom codebase — which describes the majority of enterprise operational workflows. The category includes modern BPM suites, iPaaS platforms with workflow layers, and low-code automation tools that expose rules, forms, and connectors as first-class objects.

Signs Configuration Is the Right Call

• Your process is a variant of a well-known pattern (approval, intake, escalation, reconciliation) with business-specific branching logic layered on top.
• You need to change the rules regularly, and waiting on an engineering sprint for every rule change is a real bottleneck.
• The human handoff points in the process are where most of the complexity lives — configuration platforms are usually strongest exactly there, with built-in escalation, SLA timers, and reassignment logic.
• You have (or can hire) admins who understand the business logic but aren't software engineers — configuration platforms are built for that skill profile.

Signs You Should Still Build

• The process requires algorithms or data models no platform vendor offers (custom scoring, matching, or optimization logic).
• Your scale or performance requirements exceed what configurable platforms are architected for.
• You need to embed the automation invisibly inside a product experience customers interact with directly, rather than as an internal operational tool.

Before deciding, map the process end to end. Teams that skip this step often over-scope the automation — trying to automate a process they don't yet understand well enough to know which parts are genuinely novel. The complete guide to workflow automation walks through sequencing that discovery work before any build/buy/configure decision, and grounding the process map in real customer jobs and the customer journey it supports prevents automating a step nobody actually values.

Lock-In Is a Spectrum, Not a Veto

Every option carries some form of lock-in — custom code locks you into your own team's tribal knowledge, SaaS locks you into a vendor's roadmap, and configured platforms lock you into their data model and workflow engine. Treating lock-in as binary ("we must avoid it entirely") leads to over-engineering; treating it as a spectrum lets you price it into the decision honestly.

The mitigation that matters most across all three paths is the same: write down why you chose what you chose, including the alternatives you rejected and the assumptions behind that rejection. Teams rarely revisit a build/buy/configure decision with the same rigor they applied the first time — usually because nobody can reconstruct what was actually weighed.

This is where a Decision Journal earns its keep. Prodinja's Decision Journal is designed to capture the build-vs-buy criteria and the specific assumptions behind them at the moment you make the call — so eighteen months later, when the vendor changes their pricing or the custom build starts creaking, you're reviewing your actual reasoning rather than reconstructing it from memory or old Slack threads.

Key Takeaways

• Build, buy, and configure are three genuinely different paths, not two — and configuration is the most underused of the three for enterprise process automation.
• TCO and maintenance burden usually dominate the decision more than the initial build estimate, which is visible but incomplete.
• Score candidate processes on fit, TCO, lock-in, and differentiation rather than relying on a single gut-feel judgment call.
• The "is this core to our advantage" test — would a competitor doing this identically actually matter to customers — cuts through most ambiguous cases.
• Lock-in exists in every option; treat it as a spectrum to price in, not a veto that rules out otherwise-strong choices.
• Document the reasoning, not just the decision — a reviewable record of criteria and assumptions makes the choice defensible when circumstances change.