When deciding whether to build a piece of software in-house or buy an off-the-shelf/SaaS product, what is the single most useful question to ask about the capability itself, and why does it matter more than a raw cost comparison?
answer
- core vs context
- differentiating vs commodity
- does the vendor's average serve your edge case
- revisit, don't set and forget
basics
~20 sAsk whether this makes your company special, or is something every company needs the same way, like payroll. If special, building may be worth it. If it's the same everywhere, buying is usually cheaper and faster.
solid answer
~40 sThe key question is whether the capability is 'differentiating' (tied to why customers choose you over competitors) or 'commodity' (a supporting capability every company in the industry needs, implemented roughly the same way everywhere). Commodity capabilities -- auth, payroll, ticketing, CI runners -- should almost always be bought, because a vendor amortizes R&D across many customers and reaches maturity faster than any single internal team can justify. Differentiating capabilities are worth building in-house because owning them lets you iterate on the exact behavior that creates advantage, and no vendor tunes their product to your specific edge case. This classification isn't permanent: capabilities drift from differentiating to commodity as a market matures, so the answer must be revisited over time.
go deeper
Should be able to explain the basic idea in plain language and give one example each of a commodity and a differentiating capability from a product they know.
Should apply the framework to a real decision at their company, articulating which side a specific capability falls on and why, not just reciting the definitions.
Should push back on stakeholders who mislabel a commodity capability as differentiating out of attachment or habit, and connect the decision to opportunity cost of engineering time.
Should treat the classification as a living, organization-wide input to portfolio and staffing decisions, revisited on a cadence, not a one-time answer baked into an architecture doc.
## Classify the capability, not the price tag The build-vs-buy decision starts with classifying the capability, not comparing price tags. | Class | When it applies | Examples | |---|---|---| | **commodity** (or **context**, in Wardley Mapping terminology) | it is necessary for the business to function but does not distinguish it from competitors | authentication, expense reporting, a CI pipeline, a support ticketing system | | **differentiating** (or **core**) | it directly encodes the thing customers pay for | a recommendation algorithm for a media company, a matching engine for a marketplace, the physics engine for a games studio | Every build-vs-buy conversation should open by placing the capability on this spectrum, because the spectrum, not the dollar figure, determines which factors matter. ## The two questions that classify it Mechanistically, classify a capability by asking two things: 1. **First**, if this capability vanished tomorrow, would a customer notice a difference in why they picked this company over a rival? 2. **Second**, does a mature market of vendors already sell this exact capability well? If the answer to the first is no and the second is yes, buy -- there is no advantage to protect and someone else has already paid down the maturity curve. If the answer to the first is yes, building deserves serious consideration, because a vendor's roadmap is driven by the average need across their whole customer base, and average is precisely what a differentiator cannot afford to be. ## Why the classification outranks the dollar figure This distinction exists because engineering time is the scarcest resource in most organizations, and every hour spent reinventing a commodity capability is an hour not spent on the thing that actually grows the business. This is **opportunity cost** expressed at the capability level: the true cost of building an internal ticketing system is not just the dev-months it consumes, it is the roadmap feature that did not ship because those dev-months went elsewhere. ## The trade-offs, in both directions The trade-offs run in opposite directions depending on which side of the line a capability sits. - **Buying a commodity capability** gets a team of specialists' full-time attention, a much faster time-to-market (days or weeks of integration instead of months or years of building and hardening), and the benefit of edge cases the vendor has already hit and fixed on someone else's dime -- a payments vendor has already solved the currency-rounding bug this team has not encountered yet. The cost is inheriting the vendor's roadmap, pricing power, and outages, plus the integration and data-migration cost of ever leaving. - **Building a differentiating capability** gets full control over behavior, roadmap, and intellectual property, and the ability to move at the business's pace rather than a vendor's release cadence. The cost is permanently owning the operational burden: security patching, on-call, and the multi-year cost of a team a vendor would otherwise have spread across hundreds of customers. ## Failure modes - **The most common failure mode** is misclassification in the 'build' direction: a team builds a capability because 'our workflow is special,' when in reality eighty percent of the requirement is standard and only a thin slice is genuinely unique. In production this shows up years later as a home-grown authentication system missing security features a mature identity provider shipped long ago, because the team never had spare bandwidth to catch up while also serving the business. - **The mirror failure** is buying a genuinely differentiating capability off the shelf and discovering the vendor cannot or will not build the one feature that would have been the moat, so the product quietly converges toward parity with every other customer of that vendor. - **A subtler failure** is treating the decision as permanent: a build call that was correct in year one can become a maintenance tax by year five once the market catches up and the capability commoditizes underneath the team that built it. ## A worked example **A concrete worked example.** a fintech startup building a lending product needs identity verification and KYC, a core underwriting risk model, and internal support ticketing. KYC and ticketing are commodity -- mature vendors like Persona and Zendesk sell exactly this, so buying gets the team to market in weeks and the vendor's compliance certifications come for free. The underwriting risk model is the actual product; it is what makes the startup's loan approvals faster, cheaper, or more accurate than a bank's, so it gets built in-house, with engineering time protected specifically for it. If a generic underwriting-as-a-service vendor later emerges that is genuinely as good, the calculus might flip -- but only once the capability has actually commoditized, not merely because a vendor's marketing claims it has.
- Give an example of a capability that used to be differentiating and became commodity over time.Running your own data centers and provisioning physical servers was a meaningful competitive advantage for early web companies in the mid-2000s, since it required real infrastructure expertise. By the mid-2010s, cloud providers like AWS had commoditized elastic compute so thoroughly that owning data centers became a cost and distraction rather than an edge, and most companies migrated to buying compute as a utility instead.
- Can a capability be commodity for one company and differentiating for a competitor in the same industry?Yes -- classification depends on the business model, not the industry label. A generic e-commerce checkout flow is commodity for most retailers, but for a company whose entire value proposition is a novel one-click or embedded checkout experience, that same capability is the differentiator and is worth building and owning.
- How does team size or stage of the company affect this decision even for a differentiating capability?A very early-stage startup may still choose to buy or heavily leverage an existing platform even for a differentiating capability, because it lacks the engineering capacity to build and operate anything reliably; the build decision often becomes affordable only once the company has proven the differentiator matters and can staff it properly.
It's like deciding whether to bake your own bread or buy it from a bakery: if you run a sandwich shop and the bread is what people line up for, bake it yourself and control every detail; if bread is just something the sandwich sits on, buy a decent loaf and spend your energy on the filling that actually sells the sandwich.
saying these in an interview costs you the question
- Treats build-vs-buy purely as a price comparison without discussing what the business actually gets paid for
- Assumes 'we're unique' without checking whether a mature vendor market already exists
- Never mentions that the classification can change over time
- Recommends building every capability 'for control' regardless of whether it is differentiating
- Cannot name a real example of a commodity vs. differentiating capability