What does build, buy, or partner mean?
Build, buy, or partner is the choice of where a new capability comes from. Build means you develop it yourself. Buy means you get it ready-made, by purchasing a part, licensing it, or acquiring a company. Partner means you develop it with another company. Start from the customer problem, then pick the option that solves it in time for your launch.
Where this sits on the map: Advanced planning track (Y+2 to Y+3) · Technology sourcing. See the advanced planning hub for the full track.
On this page
- The three options
- How to decide: four questions
- What a proof of concept is
- What a joint development agreement is
- Copy-and-paste prompts
- Example (fictional)
- Limits
- FAQ
What is the difference between build, buy, and partner?
The difference is who makes the capability and who controls it. When you build, you make it and own it, but it costs time and people. When you buy, you get it fast, but you pay and accept less control. When you partner, you share the work, the cost, and the control. Pragmatic Institute frames it the same way: build when “nothing like it exists,” buy when there are “existing parts to your product,” and partner when “both companies will benefit.”
| Option | Best when | Main cost | Main risk |
|---|---|---|---|
| Build | Nothing like it exists, and it is core to your product | Time and people | It takes longer than planned |
| Buy | A good enough version already exists | Money | Lock-in, and competitors can buy it too |
| Partner | A partner has the skill and both sides gain | Shared control | Unclear ownership of what you create together |
Pragmatic Institute also points out that this choice comes after you understand the market problem, not before (Pragmatic Institute). That is the product planner’s part of the job.
How do you decide whether to build, buy, or partner?
To decide, answer four questions in order. Does something good enough already exist? If yes, lean toward buying. Is this what makes your product different? If yes, lean toward building. Do you lack the skills or time while a partner has them? If yes, lean toward partnering. Then check timing: if the option cannot be ready by your launch, change the option or the launch plan.
The timing question ties back to the last two guides. Use the supplier roadmap to see when a technology is expected, and the TRL and SOP check to see whether it will really be ready.
Large company: a sourcing review with R&D, procurement, and legal, often comparing several suppliers.
Small seller: a short list of two or three factories or makers, a sample order, and a few honest emails.
What is a proof of concept (PoC)?
A proof of concept is a small test that shows an idea can work before you commit to it. One project management guide defines it as “evidence obtained from a pilot project, which is executed to demonstrate that a product idea” is feasible. In a partnership, the PoC answers one narrow question: does the partner’s technology work for your product, in your conditions?
A PoC comes before a prototype. It tests whether something can be done at all. A prototype shows what the product will look and feel like (ProjectManager).
A good PoC has a short time box, a clear pass or fail rule written before it starts, and a small budget. Without a pass rule, a PoC turns into an open-ended project.
What is a joint development agreement (JDA)?
A joint development agreement is a contract for building something together with another company. The law firm Venable calls it “an important tool to cover collaborative innovation projects among technology partners.” A JDA sets the project scope, milestones, costs, and, most importantly, who owns what. It usually comes after a successful PoC, when both sides want to keep going.
Two terms come up in almost every JDA (Venable):
- Background IP: what each side brings in, such as existing patents, know-how, or data. Each side usually keeps it.
- Foreground IP: what you create together. Ownership should be decided on purpose: one side, both sides, or one side with a license for the other.
As a planner, you do not write the contract. Your job is to bring clear answers to the business questions: what you need to own, what you only need to use, and what happens if the project stops.
Copy-and-paste prompts
How to use these:
- Copy a prompt from a gray box below.
- Replace anything in [brackets] with your own details.
- Do not paste confidential supplier documents or contract drafts into a public AI tool.
- Run Prompt 1 first, then Prompt 2 if you lean toward partnering.
- Check every fact the AI adds against your own sources.
Tip: AI can lay out the options. It cannot know your budget, your team, or what your customers value most. You fill those in.
Prompt 1: Build, buy, or partner scorecard
Help me decide whether to build, buy, or partner for a new capability.
Product: [product]
Capability we need: [what it must do]
Customer problem it solves: [problem]
Launch date: [date]
Our team and skills: [short description]
Options I know of: [suppliers, products, or possible partners]
Make a table with one row each for Build, Buy, and Partner. Columns: what it would take, time to ready, cost level (low/medium/high), control, main risk, and what I still need to find out.
Then answer these four questions with yes, no, or unknown:
1. Does something good enough already exist?
2. Is this what makes our product different?
3. Does a partner have skills we lack?
4. Can each option be ready before launch?
Do not invent suppliers, prices, or dates. Mark anything you are unsure of as "unknown."
Prompt 2: Plan a proof of concept with a partner
I want to run a proof of concept with a possible partner.
What the partner offers: [technology or material]
What our product needs it to do: [requirement]
Time we can spend: [weeks]
Budget: [amount or range]
Draft a one-page PoC plan with:
1. The single question the PoC must answer
2. A pass/fail rule we can measure
3. What each side provides (samples, data, people)
4. A timeline in weekly steps
5. Five business questions to settle before a joint development agreement, including who owns new IP and what happens if the project stops
Keep it in plain language. This is a planning draft, not legal advice.
Example (fictional)
Everything here is made up for illustration.
Back to the lunch box shop from the TRL and SOP guide. The shop wants a heat-resistant lid. It has no lab and no materials team, so building is out. Standard lids can be bought, but none handle the heat it needs. A supplier has a promising material and is looking for a first customer to test it with.
The shop chooses to partner, starting with an eight-week PoC using 50 sample lids. The pass rule: no warping after 100 dishwasher cycles. It keeps the standard lid as plan B, so the launch does not depend on the PoC passing.
Quick checklist:
☐ You started from the customer problem.
☐ You answered all four questions, including timing.
☐ Your PoC has a pass/fail rule written in advance.
☐ You know what you need to own and what you only need to use.
☐ You have a plan B that does not depend on the partner.
Limits
- This is a planning guide, not legal advice. Contracts such as JDAs need review by a qualified lawyer.
- The four questions are a starting point. Real decisions also weigh strategy, budget, and relationships.
- The lunch box example and its numbers are fictional.
- AI can miss options or invent details. Check its output against real quotes and test results.
FAQ
When should you build instead of buy?
Build when nothing good enough exists, or when the capability is what makes your product different from competitors. If anyone can buy the same part, it is hard to stand out with it.
What is the difference between a proof of concept and a prototype?
A proof of concept tests whether an idea can work at all. A prototype shows what the product will look and feel like. The PoC usually comes first.
What should a joint development agreement cover?
Common terms include the project scope and milestones, background IP each side brings, ownership of foreground IP created together, license terms, the path to a commercial product, confidentiality, and how disputes are handled.
Can AI decide build vs buy for me?
No. AI can organize the options, list questions, and draft a PoC plan. The decision depends on your budget, team, customers, and real supplier data, which only you can judge.
Where this fits: Advanced planning track · Technology sourcing, part of the product planning process guide. Previous: TRL and SOP: Is This Technology Ready for Your Launch?
Next in this track: how to estimate rough COGS (cost of goods sold) for a new product concept.
Your turn: Have you ever chosen to partner and then wished you had built or bought instead? Tell us in the comments. Your answers shape future guides.