Why the Build vs Buy Debate Misses the Point
One thing I’ve noticed over the years is that organisations often approach major technology decisions as if they have to choose a side.
Should we build?
Or should we buy?
The build-versus-buy debate appears in almost every transformation programme. Entire business cases, procurement exercises and technology strategies can be shaped around those two options, with the occasionally considered third choice of reuse.
Whether we’re discussing CRM, case management, HR platforms, citizen services or internal operational tooling, the conversation tends to start in the same place:
Which platform should we choose?
But I think that’s increasingly the wrong question.
The most successful organisations aren’t building everything themselves, nor are they placing all their faith in a single vendor platform.
Instead, they’re buying the capabilities the market already provides well, reusing what already works, and building the things that are genuinely unique to their users, services and business model.
Increasingly, low-code technology is the layer that makes this mixed approach possible.
Take CRM as an example…
The Myth of the Perfect CRM
There’s a common belief that somewhere in the market there’s a perfect Customer Relationship Management platform.
One that can manage every customer interaction, support every operational process, meet every regulatory requirement and provide every colleague with exactly the experience they need.
I’ve yet to see it.
That isn’t because CRM products are poor. Far from it. Many are incredibly capable, with mature functionality, extensive ecosystems and significant investment behind them.
The challenge is that organisations aren’t standard.
Every organisation has its own customer journeys, operational processes, policies, regulatory obligations, data, legacy systems and ways of working. Even organisations delivering similar services will have different histories, structures and constraints.
A platform might meet 70 or 80 per cent of an organisation’s needs. But that final 20 per cent is often where much of the complexity, and sometimes the differentiation, lives.
This is where organisations can run into trouble.
They buy a commercial platform and customise it so heavily that upgrades become difficult and expensive. What started as a product begins to carry many of the costs and risks of a bespoke system.
Alternatively, they build from scratch and spend significant time and money recreating capabilities the market has already solved.
Neither extreme is particularly attractive.
CRM Isn’t a Single Product
Part of the problem is the way we talk about CRM.
We often describe it as a single product performing a single function. In reality, managing relationships with customers, citizens or service users requires an ecosystem of capabilities.
That might include customer management, case management, marketing, contact centres, identity, knowledge management, workflow, document management and analytics.
It’s unlikely that one product will be the best answer to all of these needs.
More importantly, customers shouldn’t need to understand the technology sitting behind their service.
They shouldn’t need to know which team owns a process, which vendor provides a capability, or where their information is stored. Equally, colleagues shouldn’t need to navigate multiple disconnected systems simply because different products have been purchased over time.
The service should feel coherent, even when the technology supporting it comes from several places.
This is where we can learn from service design.
When we design services properly, we don’t begin with organisational structures or technology boundaries. We begin with the people using the service, the outcomes they need to achieve and the journeys they’re trying to complete.
CRM should be approached in exactly the same way.
And the same is true across other enterprise domains.
A citizen service isn’t one system.
An HR service isn’t one system.
A customer service isn’t one system.
They’re ecosystems.
The Smarter Question
Build and buy aren’t opposing strategies.
They’re both tools.
Smart organisations buy proven capabilities that are already available in the market. They reuse technology where it remains fit for purpose. They avoid spending money rebuilding functionality that doesn’t make them distinctive.
At the same time, they recognise that some things genuinely need to be tailored.
Their customer experience may be unique.
Their operational processes may reflect specific policies or regulations.
Their employees may need information brought together from multiple systems to support faster and better decisions.
Those are the areas where building can add value.
The goal shouldn’t be to minimise building at any cost.
It should be to build deliberately, focusing investment on the things that genuinely improve outcomes.
The question is no longer:
Should we build or should we buy?
It becomes:
Which capabilities genuinely differentiate us, and which have already been solved well enough by the market?
Low Code Can Provide the Missing Layer
This is where low-code platforms become interesting.
Low code is often presented as a cheaper way to build applications, or as a replacement for traditional development. I think both descriptions miss the bigger opportunity.
Low code can act as a configurable layer between users and an organisation’s technology estate.
It can bring together specialist products, existing systems and shared data through experiences and workflows designed around user needs.
Think of it as the connective tissue.
The underlying systems continue to perform the functions they’re best at. The low-code layer provides joined-up workflows, tailored user journeys, automation and role-specific views across those systems.
This means the user experience no longer has to be dictated by the limitations of a single platform.
Instead of forcing people to work around technology, technology can be designed around the needs of people.
Used well, low code can reduce the amount of bespoke development required while preserving the flexibility organisations need to evolve.
Technology Alone Won’t Solve This
Of course, low code isn’t a silver bullet.
It doesn’t remove the need for good architecture, engineering, security or governance.
A collection of independently created applications can become just as fragmented as the technology estate it was intended to replace.
This approach also requires clear ownership.
Someone must own the end-to-end service, not just the individual platforms that support it.
Technology enables the model.
Good product and service management make it sustainable.
Flexibility Matters More Than Finding a Forever Platform
Organisations often approach CRM procurement as though they’re selecting a platform that will sit at the centre of their technology estate indefinitely.
Given the time, effort and cost involved, that’s understandable.
But customer expectations change. Policies change. Organisations restructure. Technologies evolve. Vendors evolve.
The right platform today may not be the right platform for every capability tomorrow.
A mixed model creates flexibility by separating customer and colleague experiences from some of the underlying technology choices. Individual components can evolve without requiring the entire service to be rebuilt.
Instead of trying to predict which single platform will meet every future need, organisations can create an ecosystem capable of adapting as those needs change.
Buy the Capability. Build the Difference.
The future of enterprise technology is unlikely to be entirely bespoke.
It’s equally unlikely to come from a single platform.
The more pragmatic approach is to:
- Buy proven capabilities from the market.
- Reuse what already works.
- Build the experiences and processes that make the organisation different.
- Use low code to connect the pieces around user needs.
Above all, start with the problem rather than the platform.
Because customers don’t care whether an organisation built or bought its CRM.
They care whether the experience works.
And perhaps that’s why the smartest organisations have stopped asking whether to build or buy.
They’re asking “which parts are worth building?”