Every six months, somewhere in your business, a manager is staring at a spreadsheet titled "Build vs Buy: New CRM Add-on" or "Internal Reporting Tool: Vendor Comparison." The columns are price, implementation time, feature checklist, license terms. The decision lands on whichever column came out cheapest after a 3-year total cost of ownership calculation. Two years later, that decision turns out to have been the wrong one, and nobody can pinpoint exactly where the analysis went sideways.
The trouble with most build vs buy analyses is that they treat the question as if the only axes that matter are cost and time. Cost and time are real axes, but they are not the axes that decide whether the decision was right or wrong three years later. The decision lives or dies on a quieter set of factors: who owns the roadmap, how the tool integrates with the systems already in place, whether the team that uses it has the operational leverage to push for changes, and whether the cost line in year 3 is the same line you signed up for in year 1.
This piece walks through a framework for build vs buy decisions on internal business tools that surfaces those quieter factors. It is not a checklist. It is a way of structuring the conversation so the spreadsheet answers the right question.
Photo by Christina Morillo on Pexels
Why most build vs buy spreadsheets give the wrong answer
The default build vs buy spreadsheet compares two columns: total cost over some horizon (often 3 years), and time to deployment. The build column lists internal engineering cost, ongoing maintenance, and an opportunity cost line that someone added at the last minute. The buy column lists license fees, implementation fees, and an integration cost line that someone underestimated.
Three things are missing from that spreadsheet, and all three of them tend to flip the answer once they are visible.
Strategic fit decay. Vendor roadmaps drift away from your specific needs over time. The vendor that perfectly matches your use case today is optimizing for a market that includes 200 other customers, and the parts of the product they invest in are the parts most of those customers want, not the parts you specifically need. Three years in, the vendor's roadmap and your roadmap may have meaningfully diverged, and the cost of that divergence is rarely modeled in the original spreadsheet.
Integration surface area. A purchased tool has integration surface to whatever systems it touches. That surface is fragile. SSO, data exports, API access, webhook reliability, audit log access, encryption at rest, and a dozen other integration details either work the way you need them to or they do not. A build can be tuned to the integration shape you need; a buy comes with whatever the vendor decided to ship.
Switching cost compounding. Once a vendor tool is in production, the cost of switching grows over time. Data accumulates in vendor-specific formats. Workflows ossify around vendor-specific quirks. Integrations harden against vendor-specific contracts. Year 1 has low switching cost. Year 4 has very high switching cost. The vendor knows this, and so does their pricing team.
The framework below is designed to expose all three of these factors before the decision is made, not after.
Step 1: Define the strategic fit window
Before any cost analysis, write down two things on a single page.
What is the specific business outcome this tool needs to support over the next 24 to 36 months? Not the feature list. The outcome. "Reduce the time finance spends on quarterly close from 12 days to 4 days" is an outcome. "Buy an accounting tool" is a feature list.
What is the rate of change in the underlying business process the tool supports? A process that has not changed materially in 10 years and is unlikely to change in the next 5 is a different beast from a process that is being actively redesigned every quarter.
The first answer sets the bar for what the tool must do well. The second answer sets the bar for how much the tool must accommodate change without renegotiation. A high rate of change in the underlying process tilts the answer toward build, because vendor change cycles are typically slower than internal change cycles. A low rate of change tilts the answer toward buy, because the vendor's investment in a stable feature set will accrue value to you over time without you having to maintain it.
Photo by Negative Space on Pexels
Step 2: Make the operational ownership question concrete
Internal tools require operational ownership. Someone is on call when the tool breaks. Someone is responsible for keeping the data clean. Someone fields the support requests when the people who use the tool have questions.
Write down who owns each of those responsibilities in both scenarios.
In the build scenario, the internal engineering team owns development, maintenance, and on-call. A product manager or business lead owns user support, data cleanup, and roadmap prioritization.
In the buy scenario, the vendor's engineering team owns development and core uptime, but your team still owns the integration code, the data quality on your side of the integration, user support inside your company, and roadmap prioritization through whatever vendor relationship channels exist.
The buy column is not zero on the operational ownership line. It is just smaller. The spreadsheet should capture this with realistic numbers, not with the assumption that buying a vendor tool removes the operational ownership entirely.
Most build vs buy spreadsheets understate the operational ownership cost of buying, because vendor relationships look frictionless during the sales cycle and become friction-heavy once the integration is in production. - Dennis Traina, founder of 137Foundry
Step 3: Model the cost line at year 3, not year 1
Vendor pricing has predictable shapes. Year 1 is typically heavily discounted, sometimes with implementation included. Years 2 and 3 step up. Year 4 and beyond often include automatic escalators tied to inflation or to seat count growth.
A defensible cost analysis pulls the pricing through to year 5, not year 1, and assumes the vendor will exercise their negotiating leverage at each renewal. Conservatively, year 5 vendor cost can be 60 to 100 percent higher than year 1, depending on the contract structure and the vendor's market position.
The build cost line behaves differently. Year 1 has the highest cost (the initial development). Years 2 through 5 carry maintenance, incremental feature work, and occasional larger investments. The total over 5 years often crosses the buy total at some point, depending on how the buy contract is structured.
The Gartner IT cost research publishes industry benchmarks for total cost of ownership across many software categories, which is a useful sanity check. The Wikipedia overview of total cost of ownership carries the formal definitions if any of the cost categories are unfamiliar. The Project Management Institute publishes practitioner guidance on vendor lifecycle cost modeling that maps cleanly onto the build vs buy decision.
Step 4: Stress test the switching cost
The buy column has a switching cost that grows over time. The build column has one too, but it grows differently.
For the buy scenario, model two switching events: a vendor failure (the vendor goes out of business or pivots away from your use case) at year 2, and a vendor renegotiation that triples the price at year 4. For each, estimate the cost of switching to an alternative. If both numbers are large, the buy scenario is fragile to vendor behavior in a way the spreadsheet did not initially capture.
For the build scenario, model two failure modes: the key engineer who built the tool leaves, and the internal team's priorities shift away from the tool. For each, estimate the cost of either replacing the engineer or finding a vendor solution to migrate to. If both numbers are large, the build scenario is fragile to staffing decisions.
The two stress tests reveal different fragilities. Neither tool is forever. The question is which kind of forever-not-being-forever your organization is better positioned to handle.
Photo by Lucho Castro Barrantes on Pexels
Step 5: Apply the strategic fit filter, not just the cost filter
After cost, ownership, and switching cost are on the table, one more filter remains. Is this tool central to how the business differentiates itself, or is it commodity infrastructure that the business needs to operate but does not differentiate on?
A useful rule of thumb: if a competitor having the same tool, identically configured, would not meaningfully change your position in the market, the tool is commodity. Commodity tools should be bought. The vendor will invest more in features and reliability than you will, and the differentiation does not live in the tool anyway.
If a competitor having the same tool, identically configured, would visibly change your position (because the tool encodes a specific way you operate, or a specific data asset, or a specific customer relationship), the tool may be worth building. The build encodes the differentiation. A purchased tool would erode it over time.
Most internal tools are commodity in the strict sense above. Some are not, and the ones that are not deserve a build conversation even if the cost line favors buy.
The Federal Trade Commission and other competition policy sources have useful frameworks for thinking about what counts as a strategic asset versus a commodity input in a business model, which is a related but not identical question. The framing helps when it is unclear which side of the line a tool falls on.
Step 6: Write the decision and the assumptions side by side
Once the analysis is done, write the recommendation in one sentence, followed by the three assumptions it most depends on. If any of those three assumptions changes, the decision should be revisited.
A decision document looks something like this: "Recommend buy from Vendor X, contingent on: (1) the team can absorb a 60 percent price increase in year 4 without renegotiating; (2) the integration to the existing reporting pipeline is built and maintained by our team, not the vendor's; (3) the underlying business process the tool supports does not change materially in the next 24 months."
That document is the artifact. Twelve months later, when one of those assumptions starts looking shaky, the team has a clear trigger for revisiting the decision. The team also has documentation of what they were assuming when they made it, which is the part of the analysis that usually evaporates and is the part that matters most for learning.
Where 137Foundry fits in
We do this analysis for clients regularly, usually as part of a broader data integration or AI automation engagement. The build vs buy question is rarely the only question on the table; it is usually one of several decisions being made about how a workflow gets supported by software in the next two years. The services overview walks through the broader engagement structure, and our website carries the recent case studies that show how the analysis plays out in practice.
A short checklist
- Define the outcome the tool must support and the rate of change in the underlying process.
- Map operational ownership realistically across both scenarios.
- Pull cost through to year 5, not year 1, with realistic vendor pricing escalators.
- Stress test switching cost in both directions.
- Apply the strategic fit filter: commodity buys, differentiator builds.
- Document the decision with the three assumptions it depends on.
A build vs buy analysis that produces a defensible answer takes longer than a build vs buy spreadsheet. The answer is also more likely to still look right three years later, which is the only quality measure that matters for the original question.
