Every company that reaches moderate complexity hits the same question repeatedly: for this specific internal tool we need, do we build it ourselves or buy something off the shelf? The conversations usually land in one of two predictable failure modes. The engineering team argues for building because "it is just a few weeks of work" and the total is always more than a few weeks. Or leadership defaults to buying because every vendor's sales team made it sound easy and the integration costs show up later.
Both failure modes share a common root. Neither side evaluates the full cost of either option, so the decision is made on partial information that makes whichever side the decision-maker instinctively prefers look like the winner.
This article is a framework for evaluating build-vs-buy decisions that catches the variables that usually go missing, with concrete examples of where each option tends to be the right answer.
Why the Standard Debate Gets It Wrong
The standard build-vs-buy debate compares "estimated engineering hours to build" against "vendor subscription cost". This is the wrong comparison on both sides.
Engineering hours to build is always underestimated because the initial estimate is for version one. The real cost of a built tool is version one plus the ongoing maintenance, the bug fixes, the feature requests from internal users, the security patches, the version upgrades to underlying libraries, and eventually a rewrite when the original developer leaves and the new developer cannot figure out how version one works. The true lifecycle cost of building internal software is typically three to five times the initial build estimate.
Vendor subscription cost is always underestimated too, because the subscription is just the per-seat price. The real cost of a bought tool is the subscription plus the integration work to connect it to your data, the training time for your team, the cost of working around its limitations when it almost-but-not-quite fits your process, the switching cost if the vendor raises prices or gets acquired, and the security review required before sensitive data crosses the boundary. Industry research from Gartner and others consistently shows that the total cost of ownership for enterprise SaaS is two to four times the headline subscription price.
Comparing the underestimated build cost to the underestimated buy cost produces a decision that feels rigorous but is not.
Photo by StartupStockPhotos on Pixabay
The Four Variables That Should Drive the Decision
A more useful framework looks at four variables that determine where the real costs sit.
Strategic differentiation
If the tool will be part of how your company wins competitively, building usually makes sense even if the vendor option looks cheaper on paper. The reasoning is that a bought tool becomes a ceiling on what you can do; you get whatever features the vendor ships, whenever they ship them, and you cannot optimize the tool around your specific workflow. For something that is core to your competitive advantage, that ceiling is a real cost.
If the tool is pure infrastructure that every company in your space needs identically, buying almost always wins. Building your own identity provider, your own payment processor, or your own email delivery system is a mistake for 95 percent of companies because the problem is solved, the solutions are mature, and the differentiation from doing it yourself is zero.
Integration depth
Tools that need to connect to many of your internal systems get cheaper to build over time and more expensive to buy. Each new integration point with a bought tool is a new surface that breaks, a new authentication flow to maintain, and a new boundary across which your data crosses. A built tool can access your data natively and evolve its integrations as your systems evolve.
Tools that are mostly standalone get cheaper to buy. A vendor who does one thing well, connects to your data through a single API, and produces output you consume through a single channel is low integration cost by definition.
User volume and use case specificity
Internal tools used by five people for narrow, company-specific workflows usually fail when you try to buy them off the shelf. The vendor has optimized for their 90th-percentile customer, not for your specific process, and bending the tool to your workflow consumes engineering time that might as well have gone into building.
Internal tools used by many people for common workflows (expense reports, time tracking, internal communications) have mature vendor options that have seen ten years of edge cases across thousands of customers. Trying to build one of these is usually a rejection of the prior art of everyone who already solved it.
Vendor risk tolerance
If the tool handles sensitive data (customer PII, payment information, medical records, trade secrets), the vendor risk calculation changes meaningfully. A vendor acquisition, a vendor security breach, a vendor pivot away from your use case, or a vendor going out of business all translate to concrete operational risk. Some companies accept that risk in exchange for the faster time to market of buying. Others decide the risk is unacceptable and build even when it is not the cheapest option.
Photo by StartupStockPhotos on Pixabay
Running the Framework: Two Worked Examples
The framework is easier to apply with concrete cases. Here are two examples that illustrate different outcomes.
Case one: a customer-facing billing portal.
A B2B SaaS company serving mid-market customers needs a portal where customers can see invoices, update payment methods, and export billing data. Build or buy?
Strategic differentiation: low. No customer has ever chosen a vendor based on the quality of their billing portal.
Integration depth: medium. Connects to the billing system but generally not much else.
User volume and use case specificity: standard. Billing portals have been solved.
Vendor risk tolerance: moderate. The vendor holds customer payment information, so they need SOC 2 compliance, but the data is not the company's crown jewels.
The framework says buy. Every variable points to it. Harvard Business Review has published research on technology choices at this scale suggesting that companies who try to differentiate on non-differentiating features burn engineering capacity that should have gone into the actual product.
Case two: a pricing engine that computes quotes based on customer-specific rules.
A company whose competitive advantage is custom pricing for each customer needs a tool where the sales team can generate quotes quickly. Build or buy?
Strategic differentiation: high. The pricing logic is a real differentiator.
Integration depth: high. Needs access to customer data, product data, historical pricing, approval workflows, and the CRM.
User volume and use case specificity: narrow. Used by the sales team only, and the rules are specific to this company's pricing strategy.
Vendor risk tolerance: low. The pricing data is strategic, and letting a vendor host it creates exposure.
The framework says build. Every variable points to it. The company would waste the engineering time trying to bend a generic CPQ vendor to fit its pricing rules, and the end state would still be inferior to a tool built around how they actually price.
The Hybrid Option Most Teams Miss
There is a third option that the standard debate ignores: buy the foundation and build the differentiating layer on top.
Modern software infrastructure makes this easier than it used to be. Open source projects from the Linux Foundation ecosystem, hosted platform tools from GitHub, and composable SaaS building blocks mean you do not have to choose between "build from scratch" and "buy a monolithic vendor product". You can buy the parts where you have no differentiation and build only the parts that matter.
"The best build-vs-buy decisions we see treat the question as a layering exercise rather than a binary choice. Buy the authentication, the hosting, the storage, and the transactional infrastructure. Build the business logic that encodes your competitive advantage. The mistake is building something someone else has already solved for a commodity price, or buying a tool that owns the layer where your advantage lives." - Dennis Traina, founder of 137Foundry
This approach is common in the teams we work with on data integration and custom tooling. The question is almost never "build everything" vs "buy everything". It is "which layers do we own, and which layers do we rent?"
Avoiding the Three Common Traps
Even with a framework, build-vs-buy decisions get distorted by three patterns that repeat across companies.
"We can build it in a sprint"
Engineering estimates for internal tools are almost always wrong in the same direction: too low. The reason is that the estimate covers the obvious scope, not the hidden scope. The hidden scope includes authentication and user management, access control, deployment, monitoring, logging, error handling, documentation, onboarding, admin interfaces, backup, data migration, and operational support. These are all boring, they are all required, and they are collectively usually as much work as the "feature" the team wanted to build.
A rule of thumb: take the engineering estimate, add 50 percent for hidden scope, add another 20 percent for ongoing maintenance over the first year, and treat that as the build cost. If buying still looks comparable or cheaper after that, buying is probably right.
"The vendor covers 90 percent of what we need"
The last 10 percent is where the work lives. Getting 90 percent of your specific workflow supported by a generic tool usually means you have rebuilt 10 percent of the tool in custom integrations, scripts, and workarounds. Over a few years, that 10 percent of custom workaround code becomes its own maintenance burden, except now it is tightly coupled to a vendor you do not control.
If the vendor is not a clear fit for 95 percent or more of the use case, either the use case is too specific to buy, or there is a different vendor you should be evaluating. ThoughtWorks has written extensively on the failure pattern where vendor lock-in plus extensive custom workarounds produces worse outcomes than either pure build or pure buy.
"We have built X before, so we can build Y"
Engineering teams are good at pattern matching from previous builds to new ones. This is usually an asset. It becomes a trap when the pattern match skips the substantial differences between "X we built before" and "Y we are about to build". Tools that look similar often have very different edge cases, different operational requirements, and different security contexts.
When the team says "we have built this before," ask them which of the four variables above are different this time. Usually at least one is, and that one is where the previous build experience stops transferring.
Making the Decision
Once you have walked through the framework, the output is usually clearer than the starting position suggested.
If three or four of the variables point to building, build. If three or four point to buying, buy. If the variables are split, the hybrid approach is almost always the right answer: buy the commodity layers, build the differentiating layer on top.
The decision is rarely permanent. Tools get migrated in either direction over time as the company's position on those four variables changes. A built tool that is no longer strategic can be replaced with a vendor. A bought tool that has become strategic can be rebuilt when the operational cost of the vendor gap exceeds the cost of the rebuild. The goal of the decision is not to be right forever. It is to be right for the next two or three years, and to build the optionality to change course when you learn more.
For teams working on these decisions at the integration and tooling layer, https://137foundry.com works with companies to scope the build-vs-buy question concretely against their existing stack and the constraints that actually matter for their situation. More on that lives at the services page.
