Build, buy, or partner: a straight way to decide

Somewhere in the second week of every strategy engagement, the same question surfaces for each initiative on the roadmap: should we build this, buy it, or bring in a partner? It is asked as if it were one question. It is three, and they have different answers depending on what the initiative actually is.

Here is the method we use to keep the decision honest.

First, name what is being decided

"Buy versus build" hides an assumption that the thing is a product. Often it is not. Split the initiative into its parts: the model, the workflow around it, the integration into your systems, and the operational discipline that keeps it working.

The model you almost always buy, in the sense of using a vendor's API. Nobody in your position should be training foundation models. The workflow is where the real decision lives. The integration is usually a build, because it touches systems only you have. The operations are a build or a partner, and rarely a buy, because vendors sell software, not accountability.

Decide each part separately, and the fork stops looking like a cliff.

Buy when the workflow is generic and the switching cost is low

If the workflow is something thousands of companies do the same way, and a vendor has built a good product for it, buy it. Meeting transcription. Document search over a standard file store. First-line support triage with a known ticketing system.

Two conditions. The product must fit your process rather than requiring your process to fit it, and you must be able to leave. Ask for a data export on day one and see how the conversation goes. If your knowledge, your prompts, or your evaluation data would be stranded inside the vendor, you are not buying a product. You are renting a dependency.

Build when the workflow is yours

If the workflow is specific to how your business runs, is a source of advantage, or touches data you cannot send anywhere else, build it. This is the case more often than vendors would like and less often than engineering teams would like.

The test is whether a competitor could buy the same product tomorrow and get the same result. If yes, building it is vanity. If no, because the value is in how it fits your process and your data, then building is the only path to something that is actually yours.

Building well means building the whole thing: the workflow, the evaluation harness that proves it, the integration, and the operational plan. A build that stops at the demo is the worst of both options.

Partner when you need it done and owned, not just delivered

The partner option is for when the workflow is yours but the capability to build and run it is not, yet. The distinguishing feature of a good partner engagement is that it ends with your team owning the system. A partner that needs to stay forever is a vendor with a slower pitch.

Ask any partner two questions. Who on our side will own this when you leave, and what does the handoff look like? If the answers are vague, so is the exit.

A short scoring table

For each part of the initiative, write four lines. Is the workflow generic or ours? Is the data allowed to leave? Can we operate it after it is built? What does it cost to switch later? Read the four lines together and the answer is usually obvious. When it is not, the initiative is probably two initiatives and should be split.

The mistakes we see most

Buying a platform to avoid making a decision. The platform then becomes the decision, and the process bends to fit it.

Building a commodity because the team wanted to. Six months later it is a maintained internal version of something the vendor improved twice.

Partnering without an exit. The system works and the invoices never stop.

The point of the method is not to prefer one answer. It is to make sure the answer was actually chosen.