Build, Buy, or Partner: A Decision Framework for Product Teams

Sooner or later every product team meets a capability it could build itself, buy, or get through someone else. Payments. Search. A recommendation engine. Transcription. A data platform. A foothold in a country where you have no presence. The question is always framed as technical or financial, and it is almost always a strategic one: which of these things should we be the best in the world at, and which should we simply have?

I have sat on several sides of this decision. At a NYSE-listed edtech company I did the research behind choices that went each way: due diligence that surfaced an inflated valuation so that an acquisition did not go ahead, competitive benchmarking that helped surface a later acquisition, a market study where I recommended a narrower focus rather than a partnership and that recommendation was adopted, and a migration of an affiliate program onto a specialist platform. Since then I have made the same call for my own work, building lean automations myself where the capability was mine to differentiate on and buying where it was not.

What those experiences share is that the winning option was rarely the one the team started with. This post is the framework I use to get past the instinct. It has five parts: separate core from context, compare true costs, weigh control and dependency, test the other party, and keep the decision reversible. At the end there is a free scorecard that turns the criteria into a number you can argue about.

It builds on the method in from research to recommendation, because a build, buy or partner call is exactly the kind of recommendation that has to be made easy for leadership to take.

The three options are broader than they sound

People use these words loosely, so define them.

Build means developing the capability with your own people, using your own roadmap and your own standards. You own the result and the maintenance.

Buy covers more than acquiring a company. It includes licensing or subscribing to software, buying a component or data set, acquiring a team, and buying a business outright. What they share is that you pay to obtain something that already exists.

Partner covers every arrangement in which another organization provides or enables the capability while remaining independent: a technology integration, a distribution or reseller agreement, a co-development, a joint venture, a referral relationship. You share control and usually share economics.

The three sit on a spectrum of control, speed and commitment. Building gives the most control and takes the longest. Partnering is quickest to start and gives the least control. Buying sits in between and varies widely depending on whether it is a subscription you can cancel next quarter or an acquisition you cannot undo.

Step 1: Separate core from context

The first question is not about cost. It is whether the capability is part of what makes you different.

The distinction between core and context that Geoffrey Moore popularized is the most useful starting point I know. Core is what differentiates you in the eyes of customers and what you are paid for. Context is everything else you must do competently but that customers do not choose you for.

• Core activities deserve your best people and your own control. Outsourcing them hands your advantage to someone else, and over time may make that someone else your competitor.
• Context activities should be done well and cheaply, and are usually best bought or partnered, because your people add little extra value and the market already offers mature options.

Ask three questions to place a capability:

1. Would a customer name this as a reason they choose us?
2. If a competitor had exactly the same version of it, would we lose ground?
3. Does it embed knowledge about our customers that compounds as we use it?

Three yeses point to core and toward building, or at least toward owning the critical parts. Three noes point to context and toward buying or partnering.

Two cautions. First, core is not permanent: yesterday’s differentiator becomes tomorrow’s commodity, and capabilities migrate. Second, teams routinely overrate how core something is because they enjoy building it. Engineers like engineering. Ask someone who is not in love with the work.

Step 2: Compare the real cost over three years

Cost comparisons in this decision are usually distorted in predictable ways. Building is made to look cheap by leaving out maintenance and opportunity cost. Buying is made to look cheap by leaving out integration and the price rises that follow lock-in. Partnering is made to look free because no invoice arrives, while the revenue share quietly grows.

Use a three-year view, and include every category.

For building:

• Initial development, by fully loaded cost of the people involved, not just salary.
• Ongoing maintenance, which in my experience is the most underestimated line. Software is never finished. Security patches, dependencies, scale problems and changing requirements keep arriving.
• Infrastructure and tooling.
• Opportunity cost: what the same people would have built instead. This is often the largest number and almost never appears in the plan.
• The cost of delay, if building takes longer than the alternatives.

For buying:

• License or subscription fees, including how they scale with usage or seats.
• Integration and migration, which often exceeds the sticker price.
• Customization and the cost of working around what the product does not do.
• Training and change management. Adoption is a real cost, as I describe in change management for new martech.
• Price increases at renewal and the switching cost if you want to leave.
• For an acquisition, the price, the integration, retention of key people and everything the due diligence did not find.

For partnering:

• Revenue share, fees and minimums.
• The management time needed to run the relationship.
• Joint development or integration work.
• Concessions in pricing, branding or exclusivity.
• The cost of building a fallback if the partner leaves.

Then compare total cost of ownership across the three options, and attach a range to each rather than a single number. A rough model is fine. The point is that the comparison is honest about categories. You can build the same view in the product business case calculator, and the broader method for turning it into a financial argument is in how to build a business case for a product bet.

Step 3: Weigh control and dependency

Cost is only one axis. The harder question is what you give up.

Control over the roadmap. If a vendor owns the capability, your plans depend on their priorities. If they decide not to build what you need, you wait or work around.

Control over data. Who holds the data the capability produces, and can you take it with you? Data that sits in someone else’s system, in a format you cannot export, is a quiet form of lock-in.

Control over quality and experience. Customers experience your product, not the architecture behind it. If a third party’s failure becomes your failure, the dependency is real.

Concentration risk. One partner or vendor responsible for a large share of something critical is a single point of failure. I treat this like partner concentration in a marketing channel: the exposure has to be sized and managed, as in diversifying partner concentration, and you can test yours with the partner concentration risk checker.

Incentive alignment. Does the other party win when you win? A partner who earns the same however well you do has little reason to invest in your success. Check how each side is paid.

Competitive overlap. Will today’s partner become tomorrow’s competitor? Many do. If a partner could plausibly move into your space, treat the arrangement as temporary and plan for it.

Lock-in and exit. Before you commit, ask how you would leave. If the honest answer is “with great difficulty”, price that in. Contract terms matter here: exit rights, data portability, notice periods and service levels. For AI vendors specifically, the options for staying portable are covered in avoiding LLM vendor lock-in.

Step 4: Test the other party

Buying and partnering both depend on claims made by someone with an interest in you saying yes. Treat those claims the way you would in an acquisition: as a story to test.

Test whether the capability does what is claimed. Run a pilot with your own data and your own use case, not the vendor’s demo. Define the success criteria first.

Test the commercial story. For a vendor, how financially stable are they, what do their customers say, and how long have those customers stayed? For a partner, what is their real reach and track record in the thing you need?

Talk to reference customers who left. Satisfied customers are easy to find. Those who churned will tell you what the sales process did not.

For an acquisition, do real diligence. The discipline is in commercial due diligence for acquisitions: rebuild the market from the bottom up, separate a moat from incumbency, get retention by cohort, and look for revenue that is one-off dressed as recurring. In one case I worked on, that kind of scrutiny surfaced an inflated valuation, and the deal did not proceed. In another, systematic competitive benchmarking helped surface an acquisition that later changed the company’s direction. The same work can say no or yes, which is why it is worth doing properly.

Evaluate the whole deal, not only the product. Contract terms, people and culture, integration effort and the exit path all shape the outcome.

For choosing software vendors specifically, the checklist in martech vendor selection goes through the process step by step.

Step 5: Keep the decision reversible

The most underrated criterion is how hard the decision is to undo. A reversible choice can be wrong cheaply. An irreversible one has to be right.

Prefer the reversible path when you are uncertain, and look for ways to make a commitment smaller:

• Buy first, build later. Use a vendor to learn what you really need, then build the parts that turn out to be core. You pay twice, but you learn before you commit.
• Pilot a partnership with a limited scope, a short term and clear review points, before agreeing to anything exclusive.
• Build behind an interface. Design the capability so a different provider could be swapped in. It costs a little now and removes lock-in later.
• Stage the investment. Commit in tranches tied to evidence, so you can stop if the early results disappoint.
• Avoid exclusivity unless you are paid well for it and are sure.

I apply the same lens when a partnership is being compared with a narrower, self-directed approach, as in the Canada study where my recommendation to narrow the focus rather than partner was adopted. Partnerships are not bad. But when the evidence is still arriving, the option that keeps your choices open deserves extra weight.

Putting it together: a scoring approach

A structured scorecard does not make the decision for you, and it should not. What it does is force the team to state its assumptions in the open, where they can be challenged, instead of arguing from instinct.

Here is the format I use.

1. List the criteria. Typically: strategic importance, differentiation, time to market, three-year cost, control and dependency, risk, in-house capability, and reversibility.
2. Weight them. Weights should reflect the strategy, and should be agreed before anyone scores the options, otherwise people weight to favor their preferred answer.
3. Score each option for each criterion, on a simple scale, with a sentence of evidence per score.
4. Look at the pattern, not only the total. An option that scores brilliantly on everything but one critical criterion may still be wrong.
5. Run a sensitivity check. Change the weights and see whether the ranking holds. If a small change flips the answer, the decision is closer than the total suggests.

The build, buy or partner scorecard does the arithmetic and the sensitivity check for you, in your browser, with nothing stored.

Examples of how the logic plays out

These are illustrative, but each reflects a pattern I have seen.

Payments in a small software product. Context, not core. Buy. Building a compliant payment stack is expensive, the market is mature and customers do not pick you for your checkout code. The decision to make is which provider, and how to stay portable.

A recommendation engine in a content business. If recommendations drive engagement and differentiate the experience, it is core. Build the logic and own the data, and consider buying components underneath it, such as infrastructure.

Entering a new country. Often a partner is faster, but it risks handing the customer relationship to someone else. A common compromise is to start with a limited partner arrangement to learn, and to build the permanent presence once the evidence supports it. The staging principles are in a framework for international market entry.

An AI feature. Models are increasingly available as components, so buy or rent the model and build the workflow, the evaluation and the context around it, which is where differentiation tends to live. I cover this in AI product strategy.

Workflow automation inside your own company. Often a “build” using no-code and AI tools is the right answer, because requirements change often and ownership matters more than polish. That is how I run my own operations: automations built in Zapier, n8n and Claude Code, with bought services only where they are commodities.

Common mistakes

Building because it is interesting. The team’s enthusiasm is not a strategic reason.

Buying because it is fast. Speed matters, but a fast purchase that locks you in can be slower in total.

Ignoring maintenance. The cost of building is not the first release. It is everything after.

Treating a partnership as free. The costs are in revenue share, management time and lost control.

Underweighting reversibility. The right answer under uncertainty is usually the one you can change.

Letting the loudest voice decide. The criteria and weights should be agreed before the options are scored.

Skipping the diligence. Vendor and partner claims need testing as carefully as an acquisition target.

The short version

• Build, buy and partner are points on a spectrum of control, speed and commitment. “Buy” includes licensing, not only acquisitions.
• Start by separating core from context. Build or own what differentiates you. Buy or partner for the rest.
• Compare three-year total cost for each option, including maintenance, integration, opportunity cost and revenue share.
• Weigh control over the roadmap, data and quality, concentration risk, incentive alignment, competitive overlap and exit.
• Test the other party with pilots, reference customers who left and real diligence.
• Prefer reversible choices when uncertain: buy first, pilot partnerships, build behind an interface and stage the investment.
• Use a weighted scorecard to expose assumptions and run a sensitivity check, but do not let it replace judgment.

Where to go next

To make the financial argument for whichever option you favor, read how to build a business case for a product bet. To package the answer so a leadership team will act on it, from research to recommendation covers how. And for the frame that sets which capabilities are core in the first place, read how to write a product strategy that actually gets implemented.

This post is part of the product strategy guide, a reading path through all seven guides and the free tools that go with them.

---

I am Deepanshu Grover, a Senior Product Strategy Consultant in Paris. I take ambiguous, high-stakes product and business questions, run the analysis, and see the recommendation implemented. If you are weighing a build, buy or partner decision, connect on LinkedIn or get in touch.