Four questions decide build vs buy vs partner: is the capability core to your differentiation, is there a SaaS that covers 80 percent of it, do you have the engineering capacity to build and maintain, and what is the 3-year total cost.
If the capability is core and no SaaS fits, you build or partner. If a SaaS fits, you buy. The partner option dominates when the capability is semi-core, when internal capacity is tight, and when the build-to-ship window is under 12 weeks.
Below the surface
The old build-vs-buy frame has two options. The current frame has three: build in-house, buy off the shelf, or partner with an outside team. The third option used to be called outsourcing and it deserved its bad reputation. Productized engineering and AI-native dev teams changed the economics.
This is the decision framework we use on every client engagement, including our own internal builds. It takes about 20 minutes to run. The output is a clear answer, not a shortlist.
By the numbers
The decision math that changes the answer
Decision pass
4
Questions decide whether a team should build, buy, or partner.
Buy filter
80%
If a SaaS covers 80 percent and the gap is configuration, buy it.
Maintenance tail
20-40%
Annual maintenance often consumes 20 to 40 percent of build effort.
Cost horizon
3 yrs
The comparison only works when every option is modeled across 3 years.
03 / The options
The three options, stripped to their ribs
The mistake most teams make is treating this as a 2-option problem. In 2026 the partner option is often the right answer and gets missed because the frame is wrong.
Build in-house
Your engineering team writes and maintains the code. You own the IP. You carry the maintenance cost. Time to first shipped version usually ranges from 6 weeks to 12 months.
Buy off the shelf
You subscribe to software that covers the capability. You do not own the code. Time to first shipped version is days to weeks, limited by configuration and integration.
Partner with a team
A subscription dev team, fractional engineering pod, or product development agency builds and often maintains the code. You usually own the IP without carrying the hiring overhead.
The 4-question framework
Run the questions in order. The first two decide ownership and buyability. The second two decide whether the build is realistic.
- 01
Is this core to differentiation?
Core means a competitor shipping the same capability would cost you customers. If it is core, you must own it. That rules out buy.
- 02
Does a SaaS cover 80 percent?
If a SaaS covers 80 percent and the gap is configuration or light integration, buy it. If you need more than 3 months of code on top, reconsider.
- 03
Can you build and maintain?
Capacity means senior engineer time to build, review, ship, and maintain for the 3-year life of the capability. Version 1 is not the finish line.
- 04
What is the 3-year total cost?
Include build effort, maintenance, subscriptions, integration hours, review time, opportunity cost, and handoff cost if the engagement ends.
05 / Cost model
The 3-year total cost horizon
The spreadsheet wins most arguments on its own. Run the numbers for each option and include everything.
| Capability | Build | Buy | Partner |
|---|---|---|---|
| Internal tool for 10 ops users | $60K upfront plus $20K per year maintenance | $25K per year Retool | $30K upfront plus $0 maintenance when partner carries it |
| AI voice agent for 500 inbound calls/month | $180K upfront plus $60K per year | Not available at this niche | $50K upfront plus $6K/month retainer |
| Public SaaS billing | Not worth it | Stripe, roughly 3 percent of revenue | Partner is the wrong answer. Buy Stripe. |
06 / Fit test
When partner dominates and when it is wrong
Partner is not a middle answer. It wins in specific shapes and fails in specific shapes.
- 01
Partner wins when time-to-ship matters
If you need to ship in 8 weeks and a build takes 16, partner wins. Opportunity cost is real, especially on AI feature builds where the competitive window is quarters.
- 02
Partner fits semi-core capability
Semi-core means it needs to exist but does not need to differentiate. Dashboards, portals, integrations, and migrations are partner-shaped.
- 03
Partner fails when context costs dominate
If every sprint starts with 4 hours of context transfer, the model is bleeding. Write the specs or build in-house.
- 04
Partner is wrong for the kernel
Your primary product codebase is not a partner engagement. Partner can help build the next feature, but the kernel should sit in-house.
FAQ
Is partner the same as outsourcing?
A: Not anymore. Traditional outsourcing was hourly, offshore, and managed by the client. Partnering in 2026 usually means a productized or subscription dev team on a flat monthly retainer.
Can I start with a partner and move to in-house later?
A: Yes. The handoff should be written into the partner contract: all code, infrastructure, and documentation transfers at termination, with a transition-support clause of 30 to 60 days.
What is the biggest mistake in this decision?
A: Buying something that covers 40 percent of the need and calling it done. The 60 percent gap becomes shadow IT. Partner for the gap or build.
Should I build if I have AI coding tools?
A: Maybe. AI coding tools lower build and maintenance cost, which shifts the math toward build. They do not eliminate maintenance, and the framework still holds.
What if I pick wrong?
A: Frame the decision as reversible or not. Buy is usually reversible. Partner is usually reversible if the contract includes handoff. Build is the hardest to reverse because you carry the maintenance tail.