When to buy, when to build

Author: Angelica Lindqvist

At our GovTech4All Café in July, Irene Chausse, Senior product manager at Gobe Studio led a thought-provoking discussion on a critical question facing public administrations: When does it make sense to test an existing product, and when is it better to develop a tailored solution? As governments increasingly experiment with digital and AI-based solutions through pilots, this question has never been more relevant.

The session explored how synergies between public administrations can guide these decisions. When a product has already been tested in a similar use case by another administration, piloting a ready-made solution can reduce uncertainty, accelerate learning, and support scalability. Conversely, when no comparable experience or technological fit exists, a pilot may be better oriented toward custom development, allowing the solution to be shaped around specific needs, constraints, and public value objectives.   

The public sector build-vs-buy nuance 

In the startup world, the rule is simple: “Build what’s core to you, buy everything else.” But in the public sector, the decision isn’t so straightforward. Public administrations operate under unique constraints-complex procurement rules, fear of vendor lock-in, and past experiences with bad contracts. There’s no universal rule, and global experts don’t always agree. For example, Canada mandates a “buy first” policy, while the UK advocates building core platforms in-house and buying the surrounding pieces. 

The solution? Move away from rigid slogans and adopt a flexible, defensible framework to evaluate projects. 

Decomposing the "Monolith" 

One of the biggest mistakes in public sector decision-making is treating a project as a single, indivisible choice – “Should we build or buy this grants platform?” In reality, no major government platform is just one thing. A system like a grants platform is a bundle of distinct components: login, document storage, notifications, forms, reporting, and approval workflows. 

The cost of treating is as one thing: 

• Over-building: Building everything from scratch because one specific regulatory rule is complex, leading to wasted time and resources on standard components like login systems. 
• Over-customizing: Buying a massive monolithic platform and spending years forcing your processes to fit into it.

The fix: Separate the boring, standard pieces from the core rules that carry your actual public value and make a decision for each individual component. 

Placing components to the spectrum 

To determine whether to build or buy, imagine a spectrum: 

• Far left: Genuinely new or highly specific needs that no one sells (build). 
• Far right: Pure commodities that work the same everywhere, like email or cloud hosting (buy/reuse). 
• Middle: Products that exist but require configuration. 

Key insight: Technology drifts right over time. What was custom five years ago may be a commodity today. Systems must be constantly revisited to avoid maintaining outdated custom code. 

Leveraging synergies: For items on the left, look to peer administrations. If another government facing the same regulations has already piloted a solution, borrow their evidence instead of spending money to produce your own.  

The two reality-checks for building 

Before committing to building any custom component, it must pass two strict tests: 

1. Is it really unique, or just complicated? 
   Complexity is often mistaken for uniqueness. If a process is complicated because of a law or directive, every other administration under that law shares the same problem. Go find who already solved it. 
2. Cheaper today, or cheaper over time? 
   Custom software looks cheap on day one because there are no subscription fees, but you inherit 100% of the long-term maintenance burden (bugs, security patches, regulatory updates). When you buy a product, hundreds of organizations split that bill with you. 

A cautionary tale: Canada built a custom payroll system to save $70 million a year; it ended up costing over $5 billion. 

Resolving uncertainty with a pilot 

A pilot is not a “soft launch” or the first phase of a project that has already been green-lit. A real pilot is an experiment designed to answer an unknown question, and it must be allowed to fail. 

Two types of experiments: 

• Pilot to de-risk a buy: Test a promising vendor tool against one hard problem to see what breaks. 
• Pilot to discover: Build a temporary version to map and understand a tangled process from the inside. 

Case study: A grants administration built a custom pilot not to keep it forever, but to uncover the system’s seams and figure out which pieces could be bought later. They kept the source code rights to ensure future flexibility. 

Shaping system to allow room to be wrong 

The ultimate goal isn’t to make a choice that is right forever: it’s ensuring you are never trapped when things change. 

Key priniples: 

• Own your data: Always ensure data can be extracted in a standard, readable format. If you can’t get your data out, you don’t own the service.
• Own your code effectively: Keeping the source code is the bare minimum. True ownership means having the documentation and the in-house capability to run it.
• Separate builders from referees: The vendor building the system should never be the one certifying its quality or deciding next steps.
• Configure, don’t customize: Bending a standard product with heavy custom code welds you to one supplier and stops you from receiving regular updates.

The nightmare scenario: A health administration bought a proven product from another region but customized it so deeply it became a fragile, unmaintainable money pit. “Proven somewhere is not proven here”-pilot it locally first. 

Does AI change the framework?

AI lowers the barrier to building small, specific custom pieces and accelerates how fast technology moves from custom to commodity. Decisions must be reviewed more frequently. However, AI does not simplify regulations, identify your unique needs, or replace human judgment and contextual testing. The tools get cheaper, but the thinking doesn’t.

---------------------------------------

This blog post captures the key insights from our GovTech4All Café in July, where Irene Chausse from Gobe Studio explored how public administrations can navigate the build-vs-buy dilemma. The discussion highlighted the importance of decomposing projects, leveraging synergies, and using pilots to reduce uncertainty and support scalability.