Should You Build, Buy or Partner? A Decision Framework for NHS Digital Health Software

For NHS organisations investing in digital health software, one of the earliest questions is often deceptively simple: should we build something ourselves, buy an existing product, or work with a specialist partner to create and operate the solution?

It sounds like a technology decision. In reality, it is a strategic decision about where an organisation wants to own capability, risk, intellectual property, complexity and change.

The wrong choice can be expensive. A Trust may spend years developing a bespoke application only to discover that maintaining it requires a permanent software capability it never intended to create. Another organisation may procure an apparently mature commercial platform, then find that adapting it to local clinical workflows requires compromises, workarounds and integration expenditure that dwarf the original licence fee. A health system may appoint a development supplier but retain so much architectural, delivery and assurance responsibility internally that it has effectively outsourced coding rather than delivery.

There is therefore no universal answer to the build-versus-buy question. Nor should “partner” simply be treated as a third option sitting between the two. In NHS digital health, the most successful approach is often deliberately hybrid: buy the commodity capabilities that the market already solves well, retain ownership of the things that differentiate the service, and bring in specialist partners where complexity exceeds the organisation’s permanent internal capability.

The challenge is working out which parts belong in each category.

Why the build, buy or partner decision is different in healthcare

In many industries, build versus buy can be reduced to a relatively conventional calculation. How much will development cost? How much is the licence? How quickly do we need the software? Is the functionality strategically important? Those questions still matter in healthcare, but they are only the beginning.

NHS software sits inside a complex clinical, technical and organisational environment. A seemingly simple application may need to identify patients correctly, integrate with an EPR, consume or write coded clinical information, respect role-based access, support clinical workflows, maintain an auditable history, meet accessibility expectations, undergo information governance scrutiny and operate reliably when the consequences of failure are considerably more serious than a conventional business application going offline. Depending on its purpose, it may also sit within clinical safety standards, medical device regulation and other forms of assurance. These are not activities that happen after the software has been built. They influence its architecture, design, delivery process and operating model from the beginning.

This changes the economics of the decision. A commercial product costing £200,000 a year may initially appear expensive compared with allocating an internal team to create something similar. But the comparison is meaningless unless both numbers include the whole lifecycle. Internal development requires product management, user research, design, software engineering, testing, infrastructure, cyber security, clinical safety activity, integration, documentation, deployment, monitoring, support, incident management, upgrades and eventually decommissioning. Equally, the commercial product’s licence price may disguise implementation fees, EPR integration charges, interface licences, configuration work, data migration, supplier professional services, additional environments, support tiers and the internal NHS resources required to deploy and govern it.

The most important principle is therefore that the NHS organisation is choosing an operating model, not merely choosing some software. Every option creates a different distribution of responsibilities. Building concentrates more of those responsibilities internally. Buying transfers responsibility for much of the product to a supplier, but not for how safely and effectively it is deployed locally. Partnering can distribute responsibilities more flexibly, but only if the boundaries are explicit.

That last point is particularly important. Procurement can transfer contractual obligations, but it cannot eliminate organisational accountability. A supplier may produce a clinical safety case for the software it manufactures, for example, while the deploying NHS organisation still has responsibilities around how that software is configured, implemented and used within its own clinical environment. A supplier may demonstrate that its product meets baseline requirements around security or interoperability, but the Trust still needs to understand how information flows through its wider estate, who can access it, what happens if an interface fails and how incidents will be managed.

This is why simplistic arguments such as “buy is faster”, “build gives more control” or “outsourcing reduces risk” are unreliable. Each can be true, but only under particular conditions.

A better starting point is to ask what kind of problem the organisation is dealing with.

If the requirement is essentially a commodity capability with a mature supplier market, building it from scratch may create cost without meaningful advantage. If the requirement represents a genuinely distinctive clinical service or operating model that cannot be achieved through available products, custom development becomes much more defensible. If the capability is strategically important but the organisation does not have the multidisciplinary team required to deliver it safely and sustainably, partnering may provide the best balance of control and capability.

That means the first question should not be “build or buy?” It should be: what do we need to own?

When building NHS digital health software makes sense

Custom development is sometimes presented as the ambitious option: complete control, no supplier constraints and software designed exactly around local requirements. That can be true, and there are circumstances where building is unquestionably the right choice. But control is valuable only if the organisation has both a reason to exercise it and the capability to sustain it.

The strongest case for building exists when the software embodies something genuinely distinctive. Perhaps a Trust has developed a new clinical pathway that existing commercial products cannot support. An ICB may need to orchestrate information or workflows across several organisations in a way that does not map neatly to a packaged product. A specialist service may have requirements that are too niche for vendors to address economically. Or an organisation may be developing a reusable capability that it expects to become strategically important across a much wider portfolio of services.

In those situations, forcing the requirement into an existing product can result in the technology dictating the service rather than enabling it. Teams start altering clinical workflows to accommodate software limitations. Manual steps are introduced between systems. Data is re-keyed because two components cannot communicate properly. Users create spreadsheets outside the official workflow. Before long, the organisation has technically “implemented” the system but has recreated much of the complexity around it.

Building can also make sense where the organisation needs unusually high control over the roadmap. Commercial software inevitably serves multiple customers. A feature that is critical to one Trust may be relatively unimportant to the vendor’s overall customer base. Even when a supplier agrees that functionality is valuable, its roadmap may place delivery six or twelve months away. With a product owned internally, priorities can be aligned much more closely with clinical and operational needs.

There is another advantage that is often underestimated: good custom software can encode institutional knowledge. When multidisciplinary teams work directly with clinicians, administrators and patients, the resulting product can reflect details of a service that rarely appear in a procurement specification. These might include how work is handed between teams, how exceptions are handled, which information matters at different stages of a pathway, where delays really occur and what staff need to know when something goes wrong. This is one reason why discovery and user research are so important. Bespoke software has the potential to fit a service extremely well because the service itself becomes part of the design process.

But that advantage also exposes the central danger of building: organisations often budget for a project when they are actually creating a product.

Software does not become finished at go-live. Operating systems change. Browsers change. Dependencies are updated. Cyber threats evolve. National NHS services and APIs change. EPR vendors introduce new versions. Clinical requirements evolve. Accessibility issues are discovered. Users request improvements. New organisations may need to be onboarded. Defects emerge in edge cases that were impossible to anticipate during initial testing. Assurance artefacts need to remain aligned with the software as it changes.

A successful build therefore creates an ongoing obligation. The organisation needs to know who will own the roadmap in year three, not just who will write the code in year one.

Before choosing to build, leaders should be able to answer questions such as:

• Is the requirement genuinely distinctive, or are we rebuilding functionality that the market already provides effectively?
• Do we have enduring product, design, engineering, architecture, testing, security, clinical safety and service-management capability, rather than temporary project funding?
• Who will own the product roadmap after initial delivery, and how will priorities be governed?
• How will we support, monitor, patch and improve the software throughout its useful life?
• What happens if key members of the original development team leave?
• Can the architecture accommodate changes in EPRs, national NHS services, interoperability standards and organisational boundaries?
• Are we creating an asset that justifies permanent ownership, or simply solving a requirement that could have been met more cheaply elsewhere?

One useful test is to imagine the software five years after launch. If the organisation still believes this capability should be strategically owned, expects to continue investing in it and has a credible operating model for doing so, building may be entirely rational. If the enthusiasm disappears as soon as the initial transformation programme ends, the business case should be challenged.

The build decision should therefore be driven less by whether an organisation can develop software and more by whether it genuinely wants to become responsible for that software.

When buying is the better decision — and why procurement is only the beginning

Buying becomes attractive when the required capability is well understood, relatively standardised and already solved effectively by the market. There is rarely strategic value in recreating mature commodity functionality simply because an internal development team could do so. Software products can spread development, assurance, infrastructure and support costs across multiple customers, allowing an NHS organisation to access capabilities that would be uneconomical to reproduce independently.

Mature products also bring accumulated experience. A supplier serving dozens of healthcare organisations has potentially encountered edge cases, integration problems, workflow variations and operational issues that a new internal product has yet to discover. Its software may already include extensive configuration, audit functionality, administrative tooling, reporting, monitoring and resilience mechanisms that rarely appear in the first version of a bespoke system because they are not the exciting part of product development. These capabilities often become extremely important after go-live.

Speed can also be a legitimate advantage, although it should not be assumed. A configurable product with proven interoperability and a repeatable deployment model may reach users considerably faster than custom software. But purchasing an existing product does not make implementation instantaneous. Procurement, information governance, clinical safety, infrastructure, integration, configuration, testing, training, change management and deployment still take time. A product can be available today and still take many months to embed safely into a complex clinical environment.

The deeper challenge with buying is determining how much of the apparent solution is genuinely productised. A demonstration can make a platform look ready-made when significant local professional services are actually required to achieve the intended outcome. This is why procurement teams need to look beyond feature lists. Two suppliers can both answer “yes” to a requirement while offering fundamentally different levels of maturity. One may provide a configurable capability available through a well-documented interface; another may technically support the requirement only through a bespoke change delivered by its professional-services team.

Integration deserves particular scrutiny. The licence fee for the application may represent only one part of the economic picture. Connecting to an EPR or another clinical system can introduce costs associated with supplier interfaces, middleware, API access, mapping, terminology, testing, environments, authentication and ongoing support. If the product needs ten integrations across an ICS rather than one integration at a Trust, the difference between a reusable integration architecture and a collection of bespoke interfaces becomes strategically significant.

The same applies to configuration. Flexibility is valuable, but extreme configurability has a hidden cost. Somebody has to understand, govern, test and maintain all those options. A platform configured differently in every organisation can gradually become a collection of local variants that are difficult to upgrade consistently. Buying software does not necessarily remove complexity; sometimes it moves complexity from code into configuration.

Vendor dependency is another consideration, but “vendor lock-in” is often discussed too crudely. Dependency on a supplier is not automatically bad. Organisations depend on EPR providers, cloud providers, device manufacturers and many other specialist vendors because reproducing those capabilities internally would make little sense. The more useful question is whether the dependency is understood, proportionate and reversible.

A good procurement should therefore investigate not only how the organisation will enter the product, but how it could eventually leave it. Can information be exported in usable formats? Who owns configuration and derived data? Are interfaces based on open, well-understood standards where appropriate? Can another product consume the same upstream services? What support is available for migration? What happens to integrations if the supplier contract ends? Are contract extensions the only realistic option because replacing the system would require rebuilding half the surrounding architecture?

The total cost of ownership should consequently include at least four categories: the commercial cost of acquiring the platform; the cost of implementing and integrating it; the internal cost of operating and governing it; and the eventual cost of changing or exiting it.

An apparently inexpensive SaaS platform can be costly if it creates extensive manual processes or expensive integration dependencies. Conversely, a platform with a higher annual licence may be excellent value if it eliminates years of internal development, handles upgrades predictably, provides dependable support and allows the organisation to concentrate its scarce digital capability on problems that are genuinely unique.

The central test for buying is therefore not whether a product meets every imagined requirement. No mature product will perfectly reproduce every local preference. The question is whether the organisation can obtain the clinical and operational outcomes it needs without making unacceptable compromises or creating disproportionate complexity around the product.

When partnering offers more value than either building or buying

Partnering is useful precisely because many NHS digital challenges do not fit neatly into the previous two categories. The organisation may need a bespoke solution but lack sufficient internal engineering capacity. It may have purchased a commercial platform but need substantial integration and service-design work around it. It may know the problem it wants to solve but not yet know whether the final answer should be a product, custom application, integration layer or combination of all three.

A specialist delivery partner can help bridge that gap, but organisations should distinguish genuine partnership from conventional outsourcing. Hiring a supplier to provide six developers against a predetermined specification is effectively purchasing capacity. That can be perfectly appropriate, but the NHS organisation retains most of the difficult questions: whether the requirements are correct, whether the architecture makes sense, how clinical workflows should change, how risks are managed and whether the resulting solution will achieve the intended outcome.

A stronger partnership model combines disciplines. Healthcare software rarely fails because a team could not physically write the required code. More often, difficulties emerge at the boundaries between clinical need, service design, technology, integration, governance and adoption. A multidisciplinary partner can help explore the problem before committing to a solution, challenge assumptions, prototype alternatives, involve users, shape architecture and then carry the chosen approach through engineering, assurance, integration and live operation.

This can be particularly valuable where the capability is strategically important but does not justify building a permanent internal team with every required specialism. An organisation may sensibly want internal architecture leadership and product ownership while using a partner for user research, interaction design, specialist integration engineering, DevOps or software development. Another may retain its own development capability but need help integrating with several EPRs. A third might require an external team to build a product before transitioning knowledge and operational responsibility to internal staff.

Partnering also creates the opportunity to separate ownership from execution. These two ideas are frequently confused. An NHS organisation can own the product vision, architecture principles, data, roadmap and key intellectual property without employing every individual who contributes to delivery. Conversely, an organisation can employ its own developers while remaining heavily dependent on proprietary platforms, vendor-controlled interfaces or external infrastructure. Headcount does not determine strategic control.

The best partnerships therefore begin with explicit boundaries. Who owns product decisions? Who owns source code? Who maintains clinical safety documentation? Who operates cloud infrastructure? Who handles incidents outside office hours? Who is responsible for each integration? Who carries out penetration testing? Who makes architectural decisions? What happens when the engagement ends? Can another supplier reasonably take over? How will knowledge be transferred?

There is an important commercial distinction here too. An effective partner should be able to recommend that an organisation does not custom-build something when a mature product already solves the problem. If a supplier’s commercial model makes custom development the answer to every question, its incentives are misaligned with the client’s. Equally, a software vendor naturally tends to view requirements through the capabilities of its own platform. A technology-independent partner can add value by determining the best combination rather than starting with a predetermined product.

This becomes increasingly important as NHS estates grow more interconnected. A new application rarely lives independently. It may need data from one system, identity from another, workflow integration with an EPR, communications through a national service and reporting into an analytics environment. The most sensible architecture may therefore be “buy plus build”: procure a mature platform for the core capability, then create a lightweight integration or orchestration layer around it. In another case it could be “build on buy”: use established cloud, identity, messaging and terminology services while custom-building only the differentiating application. Elsewhere it may be “buy, integrate and configure”, with almost no bespoke product development at all.

The question for a partner is consequently not “can you build this?” It is “can you help us work out what should be built, what should be bought, how the pieces should connect and what we need to own afterwards?”

A practical decision framework for NHS digital leaders

The most reliable way to make the decision is to resist choosing the delivery model too early. Teams frequently move from identifying a problem directly into discussing products or writing requirements. This prematurely narrows the solution space. A better process starts with the service outcome and progressively determines which capabilities are genuinely differentiating.

First, define the problem independently of the software. “We need a patient portal” is already a solution statement. The underlying need might actually be that patients cannot see where they are in a pathway, staff spend too much time answering status calls, pre-appointment information is collected manually and correspondence is fragmented between channels. Once those needs are understood, the solution might involve an existing NHS-facing capability, extensions to current systems, workflow changes, integrations, a commercial portal, custom software or some combination of these.

Second, identify what is strategically distinctive. This is perhaps the most useful dividing line in the entire framework. Organisations should be reluctant to custom-build commodity capability and equally reluctant to outsource the parts of a service from which meaningful differentiation or control derives. Identity management, infrastructure monitoring or generic appointment functionality may be commodities in one context. A specialist clinical workflow or unique cross-organisational pathway may not be.

Third, assess the maturity of the market. The existence of several suppliers does not automatically mean a problem is well solved. Buyers should examine whether products have mature deployments comparable with the intended environment, whether interoperability is proven rather than theoretical, how easily workflows can be configured, whether suppliers have credible roadmaps and what customers actually need to do to operate the software. Where the market is mature, buying becomes more attractive. Where products require extensive compromise or the market is immature, custom work becomes easier to justify.

Fourth, calculate lifecycle economics instead of project cost. This requires comparing like with like. For build, include discovery, design, development, testing, hosting, tooling, assurance, security, integration, support, monitoring, maintenance, upgrades, product management and eventual replacement. For buy, include licences, implementation, configuration, integration, supplier services, internal deployment effort, contract management, upgrades and exit. For partner models, include both delivery cost and the internal capability required to govern the relationship effectively.

Fifth, assess the organisation’s actual capability rather than its theoretical capability. A Trust may employ developers, but does it have enough software engineering capacity to own a critical product indefinitely? Does it have experienced product leadership? User-centred design? Automated testing? Cloud engineering? Integration expertise? Clinical safety capability? Security engineering? Service management? The relevant measure is not whether these job titles appear somewhere in the organisation; it is whether enough capacity exists to support the product reliably alongside everything else the team already owns.

What should NHS organisations test before choosing build, buy or partner?

A build, buy or partner assessment should go beyond features, price and delivery timescales. NHS digital health technology also needs to work safely within the organisation’s clinical environment, integrate with the wider technology estate and remain supportable when suppliers, systems and services change.

The following questions provide a useful additional layer of due diligence. They can be applied to commercial products, bespoke software and partner-led delivery, although the organisation responsible for providing the evidence may differ between models.

A useful way to structure the final decision is to score each option against a common set of dimensions:

• Strategic differentiation: how unique is the capability to the service or organisation?
• Clinical and operational fit: how closely can the option support real workflows, including exceptions rather than only the ideal pathway?
• Time to meaningful value: not time to sign a contract or release version one, but time until users are receiving measurable benefit.
• Lifecycle cost: the realistic five-to-ten-year cost of ownership, integration, operation, change and exit.
• Interoperability: how easily will the solution exchange information with the current and likely future estate?
• Control and adaptability: can the organisation make important changes at the speed its service requires?
• Assurance burden: where do clinical safety, security, privacy, accessibility and regulatory responsibilities sit?
• Operational resilience: who supports the service, monitors it and responds when components fail?
• Capability sustainability: does the chosen model depend on individuals or skills that will be difficult to retain?
• Exitability: how difficult would it be to replace the solution, supplier or partner later?

These dimensions should not all receive equal weighting. For a patient-facing system supporting a safety-critical clinical pathway, workflow fit, clinical risk and resilience may dominate. For a short-lived administrative tool, cost and implementation speed could matter more. For an integration platform expected to connect dozens of services over a decade, interoperability, adaptability and architectural control should carry substantially greater weight.

There is also a useful second question to ask for every capability: how frequently will this need to change? High-change capabilities often benefit from greater organisational control because waiting for vendor roadmaps can become a persistent constraint. Stable, standardised capabilities are often stronger candidates for commercial products. Combine this with strategic importance and a useful pattern emerges. Commodity and stable? Buy. Distinctive and frequently changing? Build or partner. Distinctive but outside the organisation’s permanent technical capability? Partner while preserving strategic ownership. Commodity but difficult to integrate? Buy the core capability and use specialist help around the edges.

Perhaps the most important conclusion is that the decision need not be uniform across an entire programme. Large digital-health initiatives should be decomposed into capabilities before sourcing decisions are made. A single programme might use a commercial identity service, an existing EPR, national NHS APIs, a custom workflow application, a third-party communications platform and a specialist integration partner. Trying to label the entire programme as “build” or “buy” obscures the decisions that actually matter.

This composable approach has another benefit: it reduces the size of individual bets. Rather than procuring a single platform and expecting it to solve every problem, organisations can establish clear boundaries between capabilities and deliberately decide where competition, replaceability and internal control matter. Open interfaces and well-defined data ownership become strategic tools because they create future options. The goal is not to eliminate suppliers; it is to avoid making one procurement decision determine every future technology decision.

Senior leaders should also challenge the assumption that greater customisation always means better software. Healthcare organisations contain enormous local variation, some of which reflects legitimate differences in services and some of which reflects years of accumulated process. Digitising every variation exactly as it exists can hard-code yesterday’s operating model into tomorrow’s technology. A build programme should therefore not automatically reproduce current workflows, and a commercial product should not automatically force standardisation. The design process needs to distinguish valuable clinical variation from unnecessary complexity.

The same principle applies to partnership. External expertise is most valuable when it increases the organisation’s ability to make good decisions rather than creating permanent dependency. A healthy partnership should leave behind clearer architecture, better documentation, stronger internal knowledge and a solution that another competent team could operate. Dependency becomes dangerous when important decisions, system knowledge or intellectual property exist only inside the supplier relationship.

Ultimately, build, buy and partner are not competing philosophies. They are different tools for allocating capability and responsibility.

Build where the capability is strategically distinctive, available products create unacceptable compromises, change needs to happen under your control and you are prepared to own the resulting product throughout its lifecycle.

Buy where the market already solves the problem effectively, differentiation is limited, a supplier can spread development and operational costs across many customers, and the product can integrate into your environment without excessive surrounding complexity.

Partner where the outcome requires capabilities you do not sensibly need to retain permanently, where multidisciplinary healthcare expertise materially reduces delivery risk, or where the correct combination of commercial products and custom technology is not yet obvious.

For many NHS organisations, the best answer will be all three.

The strategic objective should not be to maximise the amount of software built internally, minimise the number of suppliers or outsource as much responsibility as possible. It should be to invest scarce organisational capability in the places where ownership creates the greatest value.

That requires looking beyond the initial implementation. The most useful final question is not “what is the quickest way to launch this software?” It is: five years from now, which parts of this capability will we be glad we chose to own, which will we be glad somebody else maintains, and where will we still need specialist expertise to keep the whole service evolving safely?