When to build vs. buy: a decision framework for CTOs
The build-vs-buy call is where most CTOs quietly lose a year of engineering runway. Here's the framework we use with mid-market clients — five questions, one rubric.
Every mid-market CTO we work with has a build-vs-buy story that ended badly. The build story is usually a two-year internal platform that shipped six months late and lost the strategic window it was built for. The buy story is usually a $400K/year SaaS contract for a product that solves 70% of the problem and gates the other 30% behind an enterprise tier. Both stories are avoidable, and both usually come from the same place: the decision was made on the wrong axes.
The framework that follows is what we use when a client asks us whether they should build a piece of software or buy it. It is deliberately simple — five questions and a scoring rubric — because the elaborate frameworks we tried in prior years produced worse decisions than the simple one.
The five questions
1. Is this a source of competitive differentiation?
The most important question and the one CTOs most often get wrong. A source of competitive differentiation is something your customers would notice if a competitor had it and you did not. Payroll is not differentiation for a legal tech firm. Document classification might be. Login is not differentiation for anyone. A pricing engine might be for a specialty insurer.
If the answer is no, you should almost never build. If the answer is yes, you should build unless one of the other four questions rules it out.
2. Does a mature vendor solve at least 80% of it?
The 80% number matters. A vendor that solves 50% of your problem is not a buy option — it's an integration project with a monthly bill attached. A vendor that solves 80%+ genuinely lets you outsource the undifferentiated work. If you cannot find a vendor above the 80% bar, you are either in a niche the market has not served (a signal toward build) or you are describing your requirements wrong.
3. What is the honest total cost of building?
The trap: CTOs price a build as one engineer for six months. The real cost is: build cost + integration cost + maintenance cost amortized over three years + on-call cost + upgrade cost as the underlying stack evolves. For a piece of internal software of moderate complexity in 2026, we model the three-year total cost of ownership at 2.5–3.5x the initial build estimate. If your build estimate is $200K, budget $500–$700K over three years.
4. What is the honest total cost of buying?
The trap: CTOs price a buy as the sticker license fee. The real cost is: license + implementation + custom integrations + ongoing admin + the annual price hike + the migration cost when you eventually leave. Enterprise SaaS in 2026 raises prices 12–18% annually. A $200K/year contract becomes a $340K/year contract in year four. Model it.
5. How stable are the requirements?
The most-forgotten question. If the requirements are stable over three-plus years — payroll, accounting, HRIS — buy. If the requirements are still being discovered — your core product, a new business line, an AI capability the market is still figuring out — build, because the buy option will lock you into someone else's model of the problem right at the moment you are still learning it.
The scoring rubric
Give each question a score from 0 (strong buy) to 2 (strong build):
- Q1 differentiation: no = 0, maybe = 1, yes = 2
- Q2 mature vendor solves 80%+: yes = 0, partial = 1, no = 2
- Q3 build TCO less than 3x buy TCO: no = 0, comparable = 1, yes = 2
- Q4 buy TCO stays predictable: yes = 0, some risk = 1, high price-hike risk = 2
- Q5 requirements stable 3+ years: yes = 0, evolving = 1, undefined = 2
The hybrid case is where the money is
The most common right answer in 2026 is neither pure buy nor pure build — it's a hybrid. Buy the commodity (auth, billing, email delivery, CRM, analytics ingestion). Build the layer of your product that customers actually pay for. The hybrid path minimizes differentiation loss while capping the maintenance surface area, and it is what we recommend for something like eighty percent of our mid-market clients.
The mistake CTOs make on hybrid is treating the "buy" layer as permanent. It is not. Vendors get acquired, sunset products, and raise prices. Build hybrid systems with real abstraction at the buy boundary so you can swap a vendor without a six-month project. This costs 10–15% more up front and pays for itself the first time your CRM vendor is acquired by a private equity firm.
Traps we watch clients fall into
Building because the internal team wants to
Engineers want to build. That is the correct disposition for engineers to have and the wrong disposition to base a seven-figure decision on. The build-vs-buy call has to survive the counterfactual: "if we did not have this team, would this still be the right call?"
Buying because procurement wants to
Procurement optimizes for vendor consolidation and known-quantity spend. Both are reasonable objectives. Neither is aligned with shipping the differentiating layer of your product. If a build decision is being blocked because "we already have a vendor for adjacent stuff," escalate it.
Underestimating the maintenance tax
The bill for a build-vs-buy decision does not come due at launch. It comes due in year three, when the internal system needs a re-platform and the person who built it has left. Model the three-year total cost, not the one-year build cost.
Bottom line
The build-vs-buy call is worth an hour with the whole leadership team, a real spreadsheet, and honest answers to the five questions above. The framework does not tell you what to do — it tells you which axes to argue on. Most build-vs-buy decisions that go sideways in the mid-market go sideways because the decision was made on the wrong axes, not because the score was wrong.
