The business case is solid. Two columns, a five-year horizon, stated assumptions: on one side the acquisition of a market package, licences and an integration project; on the other a bespoke build, internal effort and external services. The package wins, comfortably, and it wins alongside an argument nobody contests in a steering committee: you don’t build what already exists.

Three years later, the same organisation lives with a system its teams call “our” application. The base is indeed the vendor’s, but it carries a long list of adaptations, added one at a time, each perfectly justified at the moment it was requested. The version upgrade has become a project in its own right, and its price surprises everyone. Vendor support now applies with reservations. The organisation pays the price of standard software and carries the constraints of bespoke.

The mirror case is just as common, and less discussed: an organisation that built, with real skill, a system for a function that in no way distinguishes it from its peers — and discovers a few years later that it must maintain, on its own, a domain where it never wanted to be different, relying on the two or three people who still know how it works.

Neither story is caused by a calculation error. Both are caused by the wrong question. The buy-or-build trade-off is almost always framed as an economic comparison, when it settles two far more structural things: where the organisation accepts to operate like everyone else, and what it keeps the right to change without asking anyone’s permission. Cost is the consequence of those two decisions. It is not the criterion.

A comparison that does not compare the same things

The costed comparison is not useless. It is simply biased in a way the two-column layout renders invisible.

It first sets a price against an estimate. On one side, negotiated licences and an integration project a supplier has committed to; on the other, effort assessed internally, usually by the very people who would like to build. The two figures look alike and have entirely different status. The decision then rewards the option that can be priced, not necessarily the one that serves the organisation best.

It then puts two futures with nothing in common on the same line. The package price includes the vendor’s permanent upkeep — fixes, regulatory changes, adaptation to evolving technical foundations — but it includes neither the adaptations that will be requested, nor the upgrades that will have to catch up with them. The build estimate includes none of that, but commits a team for as long as the system lives. The two columns do not omit the same things, and they do not omit them in the same direction.

Above all, the two options do not buy the same good. One buys an operating model already formed, proven elsewhere, with its assumptions baked in. The other buys the freedom to define one. Comparing them by price is comparing a subscription with a construction: the exercise has an answer, but it says little about what was being asked. At equal cost — and this is the point — the two options leave the organisation in radically different positions regarding what it will be able to change next.

The question that settles it: where do you want to be different?

The most frequent method error is opening the market before framing the need. Once a demonstration has taken place, the need gets described in the product’s vocabulary, and the trade-off is settled before it has been examined. The decision belongs upstream, starting from business capabilities — from what the organisation must be able to do — not from a shortlist of products.

For each capability, three questions are enough to steer the choice.

Does this capability genuinely differentiate? The weak formulation is “is our process particular?”: every process is particular, and every business function will prove it. The demanding formulation is different: would we lose anything if we did this exactly the way a competitor does? And, alongside it: does that particularity come from a deliberate choice, or from history? Claimed specificity is most often sediment — the trace of a constraint that has disappeared, of a tool no longer in use, of a trade-off whose reason nobody remembers. A truly differentiating capability is rare, and it has an owner able to explain how the difference produces value. Everything else — general ledger, payroll, indirect procurement, document management — needs to be compliant, not original.

Is the market mature in this domain? In a well-standardised domain, a package encapsulates years of practice accumulated across dozens of organisations: building means relearning all of it at your own expense, including the edge cases you have not met yet. In an emerging or highly local domain, there is often nothing to buy that genuinely fits — and the “standard” on offer is then bespoke development done elsewhere, sold at a product’s price.

Who absorbs imposed change? A capability under strong regulatory pressure argues for the standard — provided the vendor genuinely maintains that compliance for the market concerned. The qualifier is not rhetorical: an international product is not necessarily maintained at the pace of local reporting, social and tax obligations. Where that coverage is delegated to a localisation module or a third-party partner, compliance risk effectively returns to the organisation, while the constraints of the package remain fully in force. This is a question to settle explicitly during selection, not a property that can be assumed.

The choice is not binary

Between a service consumed as-is and a full build lies a continuum: the package configured within its intended perimeter, the package extended through a documented extension model, an assembly of components around a market core. Placing yourself on that continuum is useful, but it is not the most important decision.

The most important decision is not to settle the question for a whole domain. A capability decomposes, and its sub-capabilities almost never share the same profile. In most domains, the bulk is common and a narrow band is differentiating. Buying the common core and building only that band — around the product rather than inside it, connected through explicit interfaces — is often the right answer, on two conditions: that the boundary is drawn deliberately, and that what gets built stays outside the product rather than embedded in its core.

That decomposition is only possible if the standard product accepts being a component: exposing its data, its events and its functions to systems it knows nothing about. A product that can only be extended from the inside forbids the split and pushes mechanically towards the drift described below. This is a selection criterion, and it carries more weight than a good part of the functional grid.

Configuration that becomes bespoke

This is where most of the value is won or lost, and the mechanism deserves precise description, because it is never the product of a single decision.

What gets loosely called “configuration” in fact covers four levels of deviation from the standard. The first is configuration within the space the vendor anticipated: options, rules, fields, approval flows already provided for. It is carried by the product and survives upgrades. The second is extension through a documented, supported extension model: the vendor commits to maintaining the attachment point, and the compatibility burden stays bounded. The third is modification of standard behaviour outside that model: it works, and nothing is promised. The fourth is modification of the core, particularly of the data model: the deepest, the least visible from outside, and the most expensive.

Between the first level and the fourth, the gap is invisible to whoever raises the request, and often similar in the immediate quote. It only surfaces at the next version. That is the whole difficulty: the cost is deferred, the commitment is immediate, and the two are not borne by the same people.

The slide always follows the same path. Each request, taken alone, is reasonable, small and cheap. Whoever approves it does not hold the upgrade budget and will probably not be in post when it is paid. Nobody keeps count of the accumulation, because no budget line is called “deviation from standard”. And the integrator is paid to satisfy the requirement, not to refuse it: refusing costs them a difficult conversation for a benefit they will not collect.

Fit-gap workshops accelerate the phenomenon when they are run without discipline. The business describes the current process, which then becomes the requirement by default; every difference from the product converts into a gap to be closed. Yet the question that goes unasked is the only one that matters: is this difference worth keeping? The default rule should be the opposite — adapt the process, unless the specificity is a source of value that is defended, named, and owned by someone.

Two simple mechanisms are enough to hold the line. The first is a deviation budget decided before selection rather than after the demonstration: how much divergence the organisation is prepared to fund, and on which sub-capabilities as a priority. The second is traceability of deviations: every adaptation carries a named owner, a written reason, its level on the scale above, and a review date. The figure to publish to the steering committee is not the number of requests handled, but the number of level-three and level-four deviations — the only indicator that makes accumulation visible while it is still reversible.

One design reminder completes the picture: the most expensive deviations are not in the screens, they are in the data model. Extending the standard object model changes what the vendor will be able to migrate, what support will be able to qualify, and what the next version is allowed to assume.

What really decides the cost: the next version

For a package, the decisive question is not “will we be able to get out?” but “will we be able to move to the next version, at a predictable cost and cadence?”. It governs everything else, because a package that can no longer be upgraded becomes a bespoke system with a licence fee attached: the drawbacks of both options combined.

For a build, the decisive question is not the initial cost but who will maintain it in year five. Building commits a permanent capability: keeping people who understand the system, a technical foundation that ages, documentation that survives departures. That is the true price of bespoke, and it rarely appears in the comparison, because it never takes the form of an identifiable invoice.

For a service consumed online, the organisation inherits the upkeep and loses the ability to say “not now”: the provider’s roadmap and calendar become its own. That is a real transfer, and it runs in both directions.

What these three formulations share deserves stating plainly: buying transfers a risk, it removes none. You exchange the risk of building badly for a dependence on a third party’s priorities, longevity and pricing policy. Both are legitimate; usually only one of them is examined.

Framing the decision

Architecture’s role here comes down to a few firm points.

Frame before opening the market, deciding by sub-capability rather than by domain, over an explicit horizon — and the same horizon for both options compared.

Write the deviation policy before selection, then make it contractual with the integrator: what counts as configuration, what belongs to the extension model, who arbitrates a request that falls outside the frame, and on what basis.

Judge candidates on their extension model and their upgrade track record, not only on functional coverage. A functional grid rewards the product that answers yes to everything — that is, precisely the product that will let the organisation dig its own hole.

Settle reversibility while you still hold negotiating power: data export in a documented form, ownership of configuration and of bespoke developments, exit conditions. After signature, these points are no longer negotiated.

Choose the right measure of success. Three years on, the relevant question is not “did the project hold its budget?” but “what level of divergence are we at, and what does the next version cost?”.

Conform, or maintain

Choosing the standard means choosing to conform: accepting that part of how the organisation works is defined outside it, by a vendor and by that vendor’s other customers. It is very often the right decision — it frees attention for the places where difference genuinely produces value. But it has to be a decision, held and explained, rather than the default consequence of a two-column table.

Choosing bespoke means choosing to maintain, indefinitely, and accepting a burden that is organisational far more than technical. It is legitimate where the difference produces value, and expensive everywhere else.

The failures observed almost never come from picking the wrong option. They come from having chosen neither: buying standard while refusing to conform to it, or building bespoke where nothing justified being different. The trade-off is structural because it distributes, for years, what the organisation will be able to change on its own and what it will have to negotiate. That distribution deserves better than a price comparison.