A Question That No Longer Fits
Every IT textbook lists Make-or-Buy as one of the central strategic decisions. Should the company build a solution itself or buy from a vendor? Classically, the answer hung on three factors: core competence, cost, time-to-market. No in-house software team? Buy. Looking for differentiation? Build. Can't decide cleanly? Buy, just to be safe.
That logic is breaking down. Not because one side wins, but because the question itself is outdated. The honest answer to "Make or Buy?" is increasingly: "Both – at different points in the stack."
What the Stack Actually Looks Like
Look at the architecture of a modern company. It buys Salesforce as a CRM platform – but builds its own Lightning apps, flows, and AI-driven data enrichment on top. It buys Snowflake as a data warehouse – but builds its own pipelines, models, and semantic layers. It buys Microsoft 365 – but builds its own Copilot extensions tapping into its own knowledge bases. It buys Stripe – but builds its own checkout flows, subscription logic, and reporting.
In every one of these cases, the platform is bought and the value sits in the build. The platform delivers what anyone can have: infrastructure, regulatory compliance, scalability, operations. The custom layer delivers what differentiates: processes, data, workflows, experience.
That's "Build the Buy" – not buying instead of building, but building on top of what you buy. It's the architecture companies have been drifting toward for years without a name for it. With AI, it's becoming the dominant pattern.
Why the Old Question Was Wrong
Classic Make-or-Buy logic assumed a solution was either bought whole or built whole. That assumption was never quite true – even SAP implementations always included substantial customising – but it was a workable simplification.
Today it's a misread. Modern platforms are APIs and extension points, not closed solutions. Salesforce without your own customisation is a generic CRM. With your own layer on top, it becomes a specific business process. Snowflake without your own models is an expensive database. With your own models, it becomes an analytical edge.
Asking "Make or Buy?" today asks about a model that no longer reflects reality. The better question: "What do we buy – and what do we build on top?"
What This Changes Economically
Three consequences slowly landing in budget discussions:
Platform licence costs are half the picture. A company licensing Salesforce for €500,000 a year typically spends another €500,000 to €1m on customising, integration, and custom development. That used to be an argument against platforms. Today it's just a realistic TCO – and the build portion produces most of the value.
Lock-in shifts but doesn't disappear. Building on Salesforce ties you to Salesforce – not just through licence costs, but through your own layer that would be worthless without the platform. That makes the platform choice more strategic than before. It's no longer a tooling decision, it's a bet on an ecosystem partner for the next decade.
In-house capability becomes more expensive and more important. Building on a platform requires people who understand the platform deeply – plus people who can build software generally. That mixed skill set is scarce and expensive in the market. It makes the difference between a platform that delivers its value and one that just sits there as a licence.
Where "Build the Buy" Wins
The strength of the model lies in division of labour. What the platform delivers, nobody needs to build. What the build delivers, nobody can buy.
Concretely: authentication, permissions, scaling, audit logs, regulatory updates, operations, backups – all topics that are painful, important, and undifferentiating. Every euro of platform spend pays off here, because the alternative would be tying up half a development team with things no customer ever cares about.
On the other side: bid evaluation logic, route optimisation, lead scoring, pricing models, automated contract negotiation, individual risk assessment – topics that are company-specific and where every small improvement is measurable in the core business. Here, building is the lever, because generic platform features level the competitive field.
Where the Model Breaks
"Build the Buy" doesn't work everywhere. Three constellations where it fails:
Platforms without serious extensibility. Some SaaS vendors claim to be platforms but deliver only a closed application with a few webhook endpoints. Building on top means building on sand. Every "Build the Buy" decision needs an honest assessment of API maturity first.
Platforms with hostile pricing. Some vendors charge per-API-call or per-custom-object so aggressively that any custom build becomes a cost trap. Here, value shifts from the customer to the vendor the moment custom development succeeds. That's economically lethal and should be a clear disqualifier.
Custom builds that just patch platform gaps. When your team spends months building what the platform should have delivered – reporting, standard workflows, simple integrations – the platform choice is wrong. Custom development should produce differentiation, not paper over platform gaps.
The Right Question in Four Steps
Instead of treating Make-or-Buy as a yes/no decision, a layered analysis pays off:
Which layer doesn't differentiate? Buy. Platform standard is enough.
Which layer differentiates but is generically solvable? Platform plus configuration. No custom code needed, but deliberate design.
Which layer differentiates and is company-specific? Build on top of the platform. This is the layer that produces competitive advantage.
Which layer is so critical that platform risk is unacceptable? Build without a platform. Rare but real – for example, at the core of an algorithmically differentiated product.
These four questions replace the old Make-or-Buy. They're more demanding because they require a layered view of your own stack. But they're closer to the reality of how modern software actually gets built.
At nh labs, we frequently see clients arrive with classic Make-or-Buy logic and end up implementing a "Build the Buy" architecture – simply because in detail, that turns out to be the more economically and strategically viable solution.
Bottom Line
The Make-or-Buy question has lost its edge because its premise no longer holds. Modern software is hybrid: bought platforms for what everyone needs, custom layers for what differentiates. Anyone still thinking in the old categories is optimising the wrong problem. Anyone embracing "Build the Buy" as architecture can design a stack where platform and build together produce more value than either alone. That's not a compromise between Make and Buy – that's the next stage.