Build vs. Buy: The Decision Is More Than Cost

The commercial platform looks pretty good. It does most of what the organization needs, can probably be implemented faster than building something from scratch, and the costs are reasonably predictable.

There are a few gaps, but at first they don't look too serious. The vendor says some can be handled through configuration. Others might require customization. A couple could perhaps be addressed by changing the way the business works.

Then someone points out that one of those gaps happens to be something the business considers pretty important.

Now the conversation gets harder. Building would provide more control, but that means taking responsibility for the technology long after the original project is finished. Buying avoids much of that responsibility, but now the organization is depending on someone else's product, priorities, and decisions.

What started as a comparison between licensing cost and development cost isn't really about cost anymore.

The 90% Fit

We've all heard some version of this: "The product does 90% of what we need."

That sounds pretty good. The trouble is that requirements don't all carry the same weight. If the missing 10% consists of things the organization can comfortably live without, the decision may be easy. But what if it includes the way the business differentiates itself, a workflow employees perform hundreds of times a day, or something customers genuinely care about?

Suddenly, 90% doesn't tell you very much.

This is where feature comparisons can become misleading. Two products can check roughly the same number of boxes while having very different implications for the business. Sometimes what a product doesn't do matters more than everything it does.

The usual answer to those gaps is customization. Buy the product and modify the parts that don't quite fit. Sometimes that's exactly the right approach, but "we'll just customize it" can cover a lot of ground.

A few extensions are one thing. Years of custom logic wrapped around a commercial product are something else. As customization grows, upgrades may require more work, integrations become more important, and people begin depending on behaviors that exist only because of those customizations. Eventually, an organization can find itself maintaining a surprising amount of custom technology around the product it bought because it didn't want to maintain custom technology. Retrofitting a commercial product around requirements it was never designed to support can also introduce complexity that would not otherwise need to exist. 

That doesn't make customization a bad idea. It simply means the word "buy" can become a little misleading.

Either Choice Comes With Baggage

Building has its own appeal, particularly when the commercial alternatives don't fit well. The organization controls what gets built, when it changes and how closely it reflects the way the business operates. In the right circumstances, that control can be extremely valuable.

But building something also means owning it—not just while the original engineering team is excited about the project, but five years later when people have moved on, technologies have aged, security expectations have changed, and the business wants capabilities nobody imagined when the system was designed.

Documentation falls behind reality. The technology needs upgrading. Knowledge becomes concentrated in fewer people. Eventually, someone asks why a critical system is running on technology nobody wants to touch anymore.

Today's custom platform has a funny way of becoming tomorrow's legacy system.

Buying shifts some of those responsibilities to someone else. The vendor maintains the product, invests in its development, operates the underlying technology and continues adding capabilities. That's a big part of what the organization is paying for.

But vendors have plans of their own. Pricing changes, licensing changes, features change, products get acquired and priorities shift. The capability the business really needs may be on the roadmap for next year, or it may never arrive.

Meanwhile, the product becomes increasingly embedded in the organization. Employees learn it, processes adapt around it, information accumulates, and other systems connect to it. Three years later, "we can always replace it" may still be technically true, but it doesn't feel nearly as simple as it did when the contract was signed.

Neither approach eliminates long-term responsibility. It changes the kind of responsibility the organization takes on.

Then there's the part that makes all of this even less tidy: the business changes.

The decision is being made for today's customers, processes, strategy and technology. The company may grow, enter another market, acquire another business or change how it serves customers. A capability that feels highly differentiating today may eventually become something every commercial platform provides. Something that looks like a commodity today may turn out to be strategically important later.

None of this means an organization should try to predict every possible future. That's a good way to make a decision so complicated that nobody makes one. But there's a difference between accepting that the future is uncertain and making a decision as though the business will never change.

The Boundary Matters More Than the Label

In practice, most organizations aren't really choosing between a world they build and a world they buy anyway.

A custom-built application may run on commercial cloud infrastructure, use managed databases, depend on third-party APIs and increasingly rely on commercial AI models. A purchased enterprise platform may contain custom workflows, integrations, extensions and business logic developed specifically for the organization.

The clean Build vs. Buy line gets blurry pretty quickly.

That's not necessarily a problem. It just means the decision is often less about picking one side and more about deciding where the boundary should sit. What is important enough for the organization to own? Where is it comfortable depending on someone else? Which responsibilities does it actually want to carry over time?

Those aren't questions that a feature matrix or a five-year cost comparison can answer by itself.

When the decision goes well, the things worth owning receive the attention and investment that ownership requires. Things someone else can provide perfectly well don't consume engineering resources simply because the organization likes to control its own destiny. Dependencies still exist, but they exist for reasons people understand.

There will always be compromises. The difference is whether those compromises were knowingly made or discovered after the contract was signed or the software was built.

Cost still matters, of course. Licensing, development, implementation, operations and time to market all belong in the conversation. But the cheapest option can create expensive constraints, while the most flexible option can create responsibilities the organization isn't prepared to carry. The product with the longest feature list can still be missing the one thing that really matters, and building something yourself doesn't automatically make it strategic.

A few years after the decision, nobody is likely to care whether the original spreadsheet said "Build" or "Buy." They'll care whether the technology still supports the business, whether the dependencies are manageable, and whether the organization has room to change.

That's probably the more useful test of whether it was a good decision in the first place.