Build, Buy, Partner... and Then What?

Technological sovereignty is also a Product strategy question. Every build, buy or partner decision shapes where knowledge, dependencies and leverage accumulate, and which choices remain available tomorrow.

Amodiovalerio Verde

• 9 min read
Build, Buy, Partner... and Then What?

An exploration of technological sovereignty - Part 3.

I thought I was writing about technological sovereignty.

Instead, I ended up back in Product.

In Part 1, I asked what we should control, what we could safely rent and which information deserves a higher protection threshold.

In Part 2, I looked at the leverage our technological dependencies create.

Those questions led me back to a familiar Product strategy decision: build, buy, partner.

It is one of those Product and strategy questions that sounds almost too familiar to examine.

We have a capability we need.

Should we build it ourselves? Should we buy an existing solution? Should we work with somebody else to create it?

I have never been entirely satisfied with the way build, buy and partner decisions are typically framed.

Cost, speed, capability and strategic importance matter.

But I think we often evaluate the decision at the moment we make it.

We pay less attention to what the decision does to us afterward, and that may be where the more important part of the strategy sits.

The usual question is about acquisition

Imagine we need a new capability.

The typical discussion starts reasonably enough.

How long would it take us to build? What would it cost? Do we have the people? Is somebody else already much better at it? How important is speed to market? Is this a differentiating capability or a commodity? How much maintenance are we signing up for?

All useful questions.

They mostly describe how we acquire the capability.

But after we have made the decision, something else starts happening. The product changes around the dependency.

Three years later, the question is no longer:

“Should we buy this?”

We already bought it.

The question becomes:

“Could we stop buying it?”

Those are very different questions.

Economics has been thinking about this for a while

I went back to some of the research on make-versus-buy decisions because I wanted to see whether this was simply a Product framing problem.

It isn't.

Transaction cost economics has spent decades looking at the boundaries between firms.

Williamson argues that relationship-specific investments and switching costs can make closer partnerships or internal ownership more sensible than ordinary market transactions.

A later meta-analysis of make, buy and alliance decisions found broad support for that logic. Uncertainty mattered too.

The Product version is simpler:

What will become specific to this relationship if we choose this provider?

You may have selected the cheapest supplier when five suppliers were interchangeable.

Three years later, you may have one supplier that is economically realistic to use.

The market did not necessarily become less competitive.

You became less portable.

A dependency can start as a commodity

Consider a hypothetical software company adding an AI capability to its customer-support product.

Several providers could do it. We could build more ourselves, but buying gives us speed and better quality today. So we buy.

Then we build around the provider.

Our evaluations reflect its strengths and weaknesses. Our workflows depend on its tool-calling behavior. Support teams learn which errors to watch for. We store history in formats optimized for its APIs. We promise customers capabilities based on how the system behaves.

None of those decisions is necessarily wrong.

Three years later, another provider offers a significantly better model.

Technically, we could switch.

Operationally, we would need to rebuild evaluations, retest critical workflows, retrain teams and change parts of the product our customers already depend on.

The original sourcing decision was reasonable. But we were buying more than a capability. We were choosing what the product would grow around.

The capability may still be a commodity.

Our implementation of it is not.

By the time the contract comes up for renewal, we are no longer negotiating under the conditions in which we originally chose the provider. The product has changed, and so has our outside option.

The supplier may still be an excellent partner.

But I would want to know: 

What will our outside option look like after three years of success?

Buying something is easy to evaluate when you enter.

Leaving exposes the architecture you built afterward.

“Strategic” is not enough to justify building

There is an obvious mistake I could make here.

If external dependencies create risk, perhaps we should build anything strategically important ourselves.

I don't think that follows.

A capability can be critical and still be a terrible thing to build.

Identity, payments, databases and networking are critical.

Most companies should not build all of them.

“Strategic” is too broad a category.

What matters is why something is strategic.

Does the capability differentiate the product? Does owning it allow us to learn something competitors cannot? Would losing access materially change our economics? Would outsourcing it expose knowledge we cannot easily reproduce? Would ownership create an advantage that justifies the cost?

Those are stronger questions.

Prahalad and Hamel's work on core competence made a related argument decades ago: competitive advantage comes partly from organizational capabilities that are difficult to imitate and can support multiple products and markets, not simply from owning every activity involved in producing the product.

There is another side to this.

Building has lock-in too.

Internal systems create maintenance.

They create organizational knowledge that can walk out of the door. They create architectures that nobody wants to touch five years later. And they consume engineering capacity that could have gone somewhere else.

The fact that I own something does not mean I have preserved optionality.

Sometimes buying gives me more optionality than building.

Especially when the market is competitive and the interface is standard.

What are we learning by doing this?

I think this is one of the questions missing most often from build-versus-buy discussions.

Where will the learning accumulate?

I have written before about the importance of turning decisions and experience into organizational knowledge. There is a prior question I had paid less attention to: which organization gets to accumulate that knowledge in the first place?

Suppose we outsource a capability because a provider can execute it better.

Good decision.

But five years later, the capability has become central to our proposition.

The provider has learned how to perform it.

We have learned how to integrate it.

Those are not the same capability.

We may have outsourced not only the work, but the learning needed to become good at it.

That may be fine. I do not need to learn how to manufacture CPUs.

But when the capability moves closer to our differentiation, I want to know where the knowledge required to compete is accumulating.

Teece's work on profiting from innovation adds another useful angle. Creating the innovation itself does not guarantee capturing its economic value. In some situations, the owners of complementary assets required to commercialize an innovation can capture substantial value from it.

Again, translate that into Product.

I may own the clever idea.

But who owns the customer relationship?

Who controls access to the data and the rights to use it? The distribution? The implementation capability? The infrastructure needed to scale it?

The answer determines who has leverage when the product becomes successful.

And what are they learning from us?

With AI, knowledge can flow in both directions.

Buying a capability may mean sharing prompts, evaluations, corrections, customer context and operational patterns. Even when contracts restrict model training, I want to understand what the provider can observe or retain, and what expertise it may develop through the relationship.

What a provider can observe, retain or use depends on the contract, the technical configuration and the safeguards in place.

That exchange may be justified. But it belongs in the sourcing decision, not only in the data-protection discussion.

My main question would be:

What knowledge and information are we sharing as part of the relationship, and how should that influence our decision?

Partnership is not simply the middle option

We often treat partnership as the middle ground between building and buying. But partnership is a different governance structure.

It can create access to expertise, distribution, technology or customers that neither side could easily create alone.

It can also let both organizations learn before making a larger commitment.

Research on real options in equity partnerships offers one way to think about this. Under uncertainty, some partnerships can preserve flexibility while organizations learn before making a deeper commitment.

I like that framing for Product.

Sometimes the right objective is not to make the perfect build-buy decision today.

It is to structure the decision so that we are allowed to know more tomorrow.

A partnership can let us test the capability before deciding whether to deepen the relationship, switch or build. But that flexibility has to be real.

A partnership where all the knowledge, technical dependency and customer relationship migrate toward the partner is not necessarily optionality.

It may gradually create dependencies that are more difficult to unwind than expected.

Sometimes the answer is both

This brought me back to double sourcing.

There is interesting economic research on firms that both make and buy the same input.

That sounds inefficient at first.

Why maintain internal capacity while also paying an external supplier?

One reason is that internal capability creates an outside option.

Research by Loertscher and Riordan models this explicitly: vertical integration can give a company the option to source internally rather than always paying the external supplier's markup, although maintaining that internal option also changes suppliers' incentives.

But build, buy and partner are not always mutually exclusive states.

You can buy the commodity layer while building the differentiating layer.

You can use a partner while retaining enough internal capability to challenge them.

Those decisions may look less efficient if you optimize only for today's delivery cost.

They may look very different if you price the option they preserve.

Optionality is not free either

Supporting two providers creates engineering complexity, while abstraction layers may prevent us from using provider-specific capabilities.

Maintaining expertise costs money, and portability can mean giving up optimizations or discounts. Even a second supplier handling only 5% of the workload is not free redundancy.

Sometimes the rational decision is to commit.

This is where I find real-options thinking useful, but insufficient on its own. Flexibility has value under uncertainty, yet commitment can create value too: better economics, deeper integration, joint investment, preferential access, a more differentiated product and faster learning.

When we discuss dependencies, a familiar question comes up:

“How do we avoid lock-in?”

Lock-in can sometimes be the consequence of a very successful optimization.

I would rather ask:

Which options are we deliberately willing to give up, and what are we receiving in return?

That makes the trade-off visible.

So what would I add to build, buy, partner?

I would keep the framework.

It is useful.

But I would change the questions underneath it.

Before deciding, I would want to understand:

What is actually differentiating here?

Not whether the capability matters. Whether owning or learning it changes our competitive position.

Where will the learning accumulate?

Inside the organization, or mainly with the provider?

What becomes specific to the relationship?

Architecture, data, teams, workflows, customer commitments. Which of those could we realistically move?

What information crosses the boundary?

What will the provider observe, retain or learn from us?

What will our outside option look like later?

Could we switch, insource or add a provider? How long would it take? What if the provider became a competitor or changed the terms?

Which options are we willing to give up?

Deeper integration may give us better economics, speed or capability. That can be worth it.

But I want to know what we are trading away.

Build, buy and partner are decisions about the future boundary of the company

This is where the connection to technological sovereignty became clearer for me.

I had initially treated them as different problems.

Sovereignty was about external technological dependency.

Build, buy, partner was a Product strategy question.

I no longer think the boundary is that clean.

Both are asking a version of the same question:

Where do I want capability, knowledge, data and leverage to accumulate?

Build puts more of them inside the organizational boundary.

Buy can give you speed, scale and expertise while moving some dependency outside it.

Partner deliberately creates a shared boundary.

None is inherently better.

The interesting part is what happens to the balance over time.

Perhaps that is what I have been missing in build-buy-partner assessments.

We treat them as sourcing decisions.

But they are also decisions about the future shape of the company.

In Part 2, I ended up asking who would have more decisions available if a dependency changed tomorrow: us or them.

I think the same test belongs here.

Because maybe the most important output of a build, buy or partner decision is not the capability we acquire.

It is the set of choices we still have afterward.

Sources

Disclaimer

The views expressed are my own and do not represent those of any current or former employer. Hypothetical scenarios are illustrative and are not intended to describe any employer, its customers, partners or internal practices.