Build vs Buy vs Generate: A Decision Tree for 2026
The build-vs-buy question has been part of software leadership for forty years. It used to have two answers and a defensible heuristic for each: build when the capability is core to your competitive advantage, buy when it is not. The boundary moved over time – payments moved from build to buy, then partially back to build, then partially back to buy – but the framework was stable. Two options, one principle.
The framework now has three options, and the principle has not been updated to match.
The third option is “generate.” Use agents to produce the implementation from a specification you own. The economics, lifecycle, and risk profile of generate are different enough from both build and buy that pretending it is a flavor of either produces the wrong decision in a growing number of cases.
The Old Two-Way Heuristic
The classic decision was straightforward. Buy was cheaper on day one and more rigid forever after. Build was more expensive on day one and more flexible forever after. The principle: buy commodity, build differentiator.
The principle worked because it captured two real cost dimensions. A bought system was cheap upfront because you were amortizing the vendor’s R&D across their customer base; it was expensive over time because you could not customize it without a vendor relationship that compensated them for the customization. A built system was expensive upfront because you were paying the full R&D cost; it was cheap over time because you owned the source and could adapt it freely.
The right answer depended on how much customization the system would require over its lifetime. For commodity functionality – accounting, email, document storage – the buy side won, because customization was rare. For differentiating functionality – pricing engines, recommendation algorithms, proprietary workflows – the build side won, because customization was constant.
This framework served the industry well. It is still mostly correct. It is no longer complete.
What Generate Changes
“Generate” is not a new category in some abstract conceptual sense. It is a new category economically. The cost structure is different from both build and buy in ways that matter.
Upfront cost is closer to buy. A precise specification and an afternoon of agent work produces a working implementation. The dollar cost of generation is small. The capital outlay required to start using it is small. By this measure, generate looks like buy.
Ongoing flexibility is closer to build. The generated artifact is source code you own. You can modify it, extend it, regenerate it. There is no vendor relationship constraining what you can do with it. By this measure, generate looks like build.
Maintenance burden is lower than either. The artifact is small, focused, and specified. The spec is the source of truth; the implementation is regeneratable. If the implementation drifts or breaks, you regenerate from the spec rather than debugging accumulated cruft. The maintenance economics are unlike either traditional option.
The risk profile is different. A generated implementation may contain subtle bugs that a vendor-produced commercial product would not, because the commercial product has been tested by thousands of customers. A generated implementation may also avoid the long-tail bugs of an aging commercial product, because the generated version is fresh and small. The risk is real but bounded; it is a different risk than either build or buy.
The result is a third option that is economically distinct: cheap to produce, owned outright, lightly maintainable, and carrying a different risk profile than either of the alternatives.
A Decision Tree That Includes Generate
We have started using a four-question decision tree with clients. The questions, in order:
1. Is the functionality required at all? This is the first question because the wrong answer to it – “yes, we need it” – is the source of more wasted engineering than any other failure mode in the industry. Most “do we need X” conversations resolve in favor of “yes, we need it” because nobody wants to be the person who said no. Force the question. If the functionality is not load-bearing for an outcome the business actually cares about, the answer is no. Skip the rest of the tree.
2. Is the functionality differentiating, or is it table-stakes? Differentiating means: this is part of what makes us better than competitors, or part of what we will iterate on continuously. Table-stakes means: every business in our category needs this, it does not vary across competitors, and we will not iterate on it. The answer reframes the next two questions.
3. If table-stakes: does a mature, well-priced vendor exist? If yes, buy. The vendor has invested years of R&D you do not need to replicate. The cost is bounded. The maintenance is theirs. The functionality is not differentiating, so vendor lock-in is acceptable. This is the classic “buy commodity” case, and it is still correct most of the time.
If no – if the existing vendor offerings are immature, overpriced, or poorly fitted to your specific needs – consider generate. A generated implementation of a table-stakes capability can fill the gap until the vendor market matures, at lower upfront cost than building from scratch and lower ongoing cost than buying a poorly-fitted product.
4. If differentiating: does the functionality require deep, ongoing iteration? Iteration here means: the team will be making material changes to behavior every quarter, indefinitely, in response to changes in the business, the data, or the user.
If yes, build. The team is going to be in the code constantly. They need to own it, understand it, evolve it. The generated implementation is at risk of being a bottleneck because every change requires re-specifying and re-generating. Building gives the team direct ownership of the evolution path.
If no – if the functionality is differentiating but does not require ongoing iteration – generate. The specification captures the differentiation. The generated implementation embodies the spec. When the spec needs to change, regenerate. This is the case where generate’s economics are most attractive: full ownership, low upfront cost, low maintenance, full flexibility.
Where the Old Framework Was Wrong
The old build-vs-buy framework assumed that ownership of source code was the binary that mattered. It is not, anymore. What matters is ownership of specification. The source code is regeneratable; the specification, if it is the durable artifact, is the thing you actually want to own.
This reframes a number of historical decisions. Internal tools that used to be “build because we want to customize them” were often actually cases of “we want to own the specification, the implementation is incidental.” Generate satisfies this need at lower cost than the build option ever did. Internal admin panels, customer-facing forms, reporting glue, scheduled workflows – all of these have moved, for us, from “build, reluctantly” to “generate, gladly.”
It also reframes some of the buy decisions. A commercial product that fits 80% of your needs and forces you into expensive customization for the remaining 20% used to be evaluated on whether the customization cost was worth the rest of the product’s value. With generate available, the calculation shifts: maybe the 80% can also be generated to your specification, at lower customization cost than the commercial product, with full ownership. The default answer is not always “generate” – the commercial product still has years of edge cases baked in – but the calculation is different.
What Doesn’t Change
The traditional reasons to buy are still valid for many systems. Anything where the vendor has invested significantly more in robustness, security, or compliance than you ever will – accounting platforms, email infrastructure, identity providers – is still a buy. The vendor’s track record is the artifact you cannot replicate. Generating your own is a category error.
The traditional reasons to build are still valid for systems where the team needs to be in the code daily. Anything where evolution is constant, deep, and unpredictable – core product features, proprietary algorithms, real-time systems with bespoke performance characteristics – is still a build. The agent can help with implementation, but the engineering team has to own the system’s evolution end-to-end.
What changes is the middle. The large category of internal-but-differentiating, or specialized-but-not-iteration-heavy, or table-stakes-but-poorly-served-by-vendors – that middle is where generate has displaced both build and buy as the right answer. And the middle is a much larger fraction of total enterprise software than most leaders realize.
The Honest Statement
The build-vs-buy heuristic served the industry for forty years. It is incomplete now. The orgs that still operate on the two-way version are systematically over-paying – either by buying systems they should be generating, or by building systems they should be generating.
Add the third option. Update the heuristic. Stop pretending generate is a flavor of one of the other two. It is its own category, with its own economics, and it deserves to be considered on its own terms.
