Build, buy or partner: the question behind the question

Choosing how to source a capability determines more than who delivers the first version. It shapes the changes your business can make, the skills it must retain and the dependencies it will carry. Those responsibilities deserve attention before proposals are compared.

Start by deciding where control creates business value and what your organisation is prepared to sustain. That gives build, buy and partner a common basis for assessment.

Identify what needs to be distinctive

Separate the capabilities customers value from the supporting functions needed to operate them. A specialised planning method might create an advantage. User access, standard reporting and routine administration may simply need to work reliably.

This distinction helps define where flexibility is essential. Ask which parts of the process are likely to change, who decides those changes and what would be lost if the business adopted a standard approach.

Challenge claims that every requirement is unique. Some differences reflect accumulated habits rather than a commercial advantage. Equally, a standard product that cannot accommodate an essential operating constraint may be a poor fit despite an attractive demonstration.

Define the few requirements that would genuinely change the sourcing decision. Use those to test options before investing in a large specification or procurement exercise.

Build where control justifies ongoing ownership

Building can give the business room to develop a capability around its particular needs. It also creates responsibilities for product decisions, maintenance, security, support and future development.

Assess whether the organisation can direct the work and retain enough knowledge to operate it. Using an external development team still requires someone inside the business to resolve priorities, accept trade-offs and own the result.

Consider what happens after the initial team moves on. Who will understand the design? How will defects be handled? What budget will keep the capability useful as operating needs and connected systems change?

Access to source code is one form of control. The practical ability to maintain and change the software depends on documentation, skills and a workable development process. Include all of those in the assessment.

Buy with a clear view of the fit

Buying an established product can reduce the work needed to create common capabilities. The decision still needs to account for configuration, integration, data migration and changes to the way people work.

Test essential requirements using realistic scenarios. Ask users to work through the difficult cases, including the ones currently handled outside the main system. Establish where the business can adapt and where a limitation would materially affect the outcome.

Understand how extensions are maintained, how updates affect them and what support is included. Heavy customisation can reduce the advantage of adopting a standard product while leaving the business dependent on its supplier.

Assess the ongoing relationship too. Pricing, access to data, supplier responsiveness and the ability to move to another arrangement all affect the value of the choice. Make those dependencies visible alongside the functionality.

Partner with responsibilities agreed

A partner can contribute specialist knowledge, development capability or access to technology that the business cannot justify maintaining alone. The arrangement needs clarity about who owns the product direction and who can make consequential decisions.

Agree how priorities will be set, what each party contributes and how knowledge will be shared. Establish responsibilities for support, future changes and continuity if the relationship ends.

Check that the commercial arrangement supports the outcome you need. A partner paid to deliver a defined scope may have different incentives from one sharing responsibility for an evolving product. Neither model resolves ambiguity about authority or acceptance.

Include a practical handover or exit path in the discussion. Independence depends on usable knowledge and access as well as the agreed rights.

Compare the choices through an operating scenario

Consider a hypothetical industrial maintenance business developing a planning tool. Its distinctive capability is matching specialist crews to complex shutdown work. It also needs familiar functions for recording jobs, managing access and producing reports.

Building the whole platform could provide flexibility, but would require maintaining functions that contribute little to its advantage. Buying might cover those functions while constraining the matching method. A partner might help create the specialist component, provided responsibilities and knowledge transfer are clear.

A combined approach could use an established product for the common functions and a separately developed matching component. That option adds an integration boundary that someone must own. It needs the same scrutiny as the other choices.

Compare the options over the period the business expects to use the capability. Include the initial investment, internal capacity, operating cost, ability to change and cost of leaving. Show what happens if requirements evolve or a key supplier becomes unavailable.

Make a choice the business can support

Before committing, establish where you need control, which responsibilities you can carry and which dependencies you are willing to accept. Identify the person accountable for those responsibilities after delivery.

If no option is supportable, narrow the ambition or resolve the capability gap first. A useful next step is a short assessment of the essential requirements against realistic build, buy and partner options. The result should explain both how the capability will be delivered and how the business will sustain it.