Buy or build. There is no universal rule, and public sector experts rarely agree. For instance, Canada prioritizes a strict "buy" policy, whereas the United Kingdom recommends building core platforms in-house while buying the surrounding modules. Consequently, every time a public agency launches a new initiative, the exact same dilemma emerges: should we acquire an off-the-shelf commercial product or build a custom solution from scratch? It feels like a binary choice—and creates a false impression that a single decision must apply to the entire project.

This article proposes a preliminary step that public authorities rarely take: breaking a system down into its individual components and asking, for each piece: Is this core, strategic, or innovative for our agency, or is it shared infrastructure that everyone needs?

A System Is Not a Single Decision

"Should we build or buy the grant platform?" Framing the question that way is the first mistake we usually make, because "the grant platform" is not one single thing. It is a way to authenticate users, a place to store documents, a notification engine, forms, reports, an approval workflow, and the logic that encodes the specific rules of that administration. It isn't one decision—it's eight, and they deserve eight answers.

When you decide for the whole block instead of the individual pieces, you fall into one of two mistakes. Either the specific part causes panic—"our regulations are complicated, no product will cover them"—and everything is built from scratch, including common pieces like user login or document management, which then have to be maintained indefinitely. Or you buy a massive platform that promises to do it all and assume it will fit as-is, without identifying which parts will demand the most attention. Both mistakes stem from failing to break the system down first.

Once the system is broken down into pieces, it’s time to analyze and understand each one, placing them along a spectrum ranging from what is uniquely ours—the core, the strategic, the innovative—to the common infrastructure that everyone needs. Where each piece lands determines the answer: build toward one end, buy toward the other.

Complexity Is Not Uniqueness

Analyzing and placing each piece requires a critical mindset, because it is easy to misclassify them. A very common mistake is confusing complexity with uniqueness. "This is full of rules, deadlines, and controls; it has to be ours." It sounds reasonable, but it is almost always false, because the complexity of a public process is rarely unique. It often comes from the law, regulations, or directives—meaning it isn't a differentiator. Any other administration subject to the same rule faces the exact same complexity. And other times, that complexity comes from a process that has become convoluted over the years and could be simplified instead of transferred as-is into the new system.

So, when should I build?

The first case is when the piece is genuinely unique: the core of the institution's mission, a differentiating factor, or strategic for sovereignty. Sometimes a piece does the exact same thing a market product would do, yet it must still be built in-house because what is at stake is control: health, identity, and security data; critical infrastructure upon which an essential service depends. In those cases, relying on a single vendor stops being a question of cost and becomes a question of who controls the public infrastructure. This is what the City of Boston did when it built its own middleware layer between its services and AI models: it bought the common elements and built the strategic part that guarantees its autonomy from any vendor.

The second case is when there is no market solution. Not because the piece is particularly unique, but because no one sells it—either because it is too new or because it is a public sector niche that no vendor has found profitable.

Outside of those two cases, the piece is common—and the default place for common elements is to buy.

Buying Is Also an Active Decision

Deciding to buy doesn't mean the decision is finished. Buying well requires three judgments for every purchased piece—judgments that are only possible if you have broken down and thoroughly understood the piece first.

The first: will we have to change our processes to fit the product? And if so, are we willing to do so? A good market product brings its own way of working. Often, adapting the process to the product is exactly what should be done—and the hardest thing to do.

The second: what needs to be configured, and where is the temptation to customize? Configuring—that is, adjusting the options the product already offers—is recommended. Customizing, on the other hand—modifying its code to force it into a legacy way of working—should be avoided: every modification creates vendor lock-in and usually prevents receiving updates, leaving you maintaining an obsolete version of a product you are still paying for.

The third: will we need to build something specific to complement it? Sometimes a product covers 90% of the needs, leaving a minor, highly specific piece that is unique to us. That small custom development, built around the product rather than inside it, is often the difference between a purchase that fits and one that doesn't.

These three judgments are why breaking things down matters just as much on the buy side as it does on the build side. Without decomposition, you buy an entire block blindly and hope it fits. With it, you know in advance which pieces will require changing how you work, which ones to handle with care, and which ones to complement.

The Phoenix Case

The most expensive case we know of is, precisely, that of an administration that bought, but failed to make any of those judgments. In 2009, the Government of Canada acquired a solid commercial product for its payroll. But its civil service had over a hundred collective agreements and tens of thousands of salary rules. Instead of asking which processes it should simplify to use the product, it decided to customize it to fit its processes, adding over two hundred custom developments on top. The system, known as Phoenix, stopped paying tens of thousands of civil servants correctly and has cost more than $5 billion. Its Auditor General called it "an incomprehensible management failure."

Phoenix didn't fail because it bought a product. It failed because it bought without deciding: without distinguishing what was common and should adapt to the product, and what was truly its own.

Breaking It Down Is the Job

Ultimately, the real work isn't in saying "we decided to buy" or "we decided to build." It's in the preliminary step of breaking the system into pieces and classifying each one with a critical eye. Is this ours (core, strategic, innovative), or does it just seem that way? And if it is common, what will it require for me to buy it well?

And this is work that must be redone every so often, because classifications are not permanent: the boundary moves. A few years ago, for a system to do something with artificial intelligence, you had to train a custom model in-house. Today, much of that is solved with a general-purpose model. The piece that yesterday had no choice but to be built is bought today. What was classified correctly once should be re-examined.

Doing that work protects you from two expensive mistakes at once: building what could have been bought better and cheaper, and buying what should have been controlled—or buying without anticipating that it would force you to overhaul the entire organization's processes. What almost never works is buying everything or building everything. Instead, the key is an uneven mix, decided piece by piece. You don't need a twenty-variable matrix. You need to break it down and ask, for each piece, the single question that brings order to the rest.

‍