Build vs. buy vs. configure: a non-technical operator's framework

The build-vs-buy-vs-configure question gets framed as a binary by most vendors — and unsurprisingly, vendors of platforms recommend platforms while vendors of custom software recommend custom. This is the framework an operator should actually use, written without a horse in the race for any specific outcome.

Why “configure” usually wins before either of the others

The default decision frame for most operators is buy-vs-build. The frame is incomplete. The third option — configure better what you already have — is the right answer in roughly 60% of cases where operators initially think they need something else.

The reason is that platforms are more capable, more flexible, and more configurable than most teams use them for. The team adopted the platform years ago, configured it once, hit a wall, started adding workarounds, and now perceives the platform as the problem. The platform usually isn’t the problem; the configuration is.

A configuration audit costs roughly 5% of what a platform migration costs and about 1% of what a custom build costs. It deserves first look.

When configure-better doesn’t get there

Configuration has a real ceiling. When the platform’s data model genuinely doesn’t fit the business, or when the platform doesn’t support a workflow that’s core to the business, configuration won’t close the gap.

Honest signs configuration won’t get there:

• The platform’s core entity model (account, deal, project, order) doesn’t match the business’s actual entities
• Required fields the platform enforces don’t apply to the business
• Required workflow steps the platform mandates conflict with how the business actually operates
• Custom code is required to make basic flows work

When two or more of these are true, no amount of better configuration will fix it. Time to consider buying differently.

How to evaluate a buy decision well

Buying a different platform is a serious move — the migration cost is real, the team disruption is real, the integration rewiring is real. The decision should be evaluated on four axes, not just feature lists.

Outcome fit. Will the platform produce the business outcomes you actually need? Demos optimize for showing capability; you’re trying to evaluate fit. The right way is to walk the platform through your three or four most important workflows and see whether each runs cleanly.

Integration fit. What other systems does the platform need to talk to, and how well does it do that? A platform that handles your core workflow beautifully but integrates poorly with the rest of your stack creates a new fragility.

Total cost over five years. Subscription cost is the visible piece. Add in implementation cost, training cost, integration cost, and the operator hours required to keep it running. Compare like-for-like across the platforms in the running.

Operational complexity. How much specialized knowledge does the platform require to run? Some platforms are powerful and require dedicated administrators. Some are simpler and limit what you can do. Match the complexity to your operating model.

A four-axis scoring sheet across three or four candidate platforms is usually enough to make the right call. Avoid scoring on feature checklists alone — they hide the operational reality.

When custom actually makes sense

Custom software is the right answer when three conditions are simultaneously true:

Condition one — the workflow is genuinely unique. Not “we do it differently than competitors”; actually structurally different in a way that no platform models. Most operators who think they have a unique workflow have an idiosyncratic version of a common workflow. Genuine uniqueness is rarer.

Condition two — off-the-shelf has been honestly tried. Not “we looked at a couple options”; actually configured and run. The bar is real deployment, real team usage, real assessment of whether the gap is fundamental or fixable.

Condition three — the business is ready for continuous custody. Custom software that gets built and walked away from accumulates technical debt and becomes a liability within 18–24 months. Custom software that’s tended evolves with the business and stays an asset. The model the business signs up for matters more than the build itself.

When all three conditions are met, custom is the right answer and the cost premium is worth it. When any one of them is missing, custom is more expensive than the alternative even when the visible quote looks comparable.

The five-year math

Run the math over a five-year window. Three columns:

Cost line	Configure better	Buy a new platform	Build custom
Initial implementation / build	$5K–$30K	$30K–$150K	$150K–$600K+
Annual platform / subscription	Existing	$20K–$80K	$0 (you own the code, but tend it)
Annual maintenance / continuous-custody	$0–$15K	$5K–$15K	$30K–$80K
Internal time year 1	Low	Medium	High
Internal time years 2–5	Low	Low	Medium
Cost of being wrong	Low	Medium (you can switch again)	High (you can’t easily exit)

The visible quote is one number. The five-year cost is what you actually pay. Most operators who run the math honestly end up at “configure better” or “buy a different platform that fits” rather than “build custom.”

When custom is the right call, the math will say so clearly — the business outcomes will be valuable enough that the cost premium is paid back in less than three years. If the math doesn’t say that, custom probably isn’t the answer yet.

What to ask yourself before deciding

Three honest questions before committing to any of the three paths:

1. Have we genuinely tried to configure what we have? Not in passing — really tried, with a fresh look at the platform’s full capabilities and a willingness to redesign workflows around what the platform does well?

2. If we buy a different platform, what’s our exit plan from this one in three years? Platforms get outgrown. The cost of switching is real. Buying with an exit plan in mind keeps you from being stuck the next time.

3. If we build custom, who’s running it in three years? Custom software needs ongoing care. Not “the original developer who left” or “we’ll figure it out later.” A specific, named, sustainable answer — or the build is the wrong call regardless of the technical fit.

The framework collapses to one principle: software decisions are operating decisions. The right answer is the one that fits how the business actually wants to operate, including what it wants to outsource and what it wants to keep close. Match the decision to the operating model, and most of the build-vs-buy debate resolves itself.