Most enterprises default
to build. That's usually
the wrong answer.

The build vs. buy vs. partner decision is the most consequential recurring decision in enterprise commerce strategy, and it is almost never made on first principles. It gets made on the basis of existing vendor relationships, internal politics, a technology team's preferences about what it wants to build, and a risk-aversion bias toward build that feels safe but is almost never justified by the actual economics. The result is a pattern I see repeat: enterprises spend 18–36 months and significant capital building something that an existing vendor already built better, lose the market timing window they were trying to capture, and end up with a maintenance obligation that consumes resources for years.

The bias toward build is not irrational in isolation. Large organizations have technology teams, and technology teams have legitimate reasons to prefer building: control over the roadmap, no vendor dependency, customization flexibility, no ongoing licensing costs. The problem is that these factors get evaluated against an unrealistically optimistic view of the build timeline and cost, and against a systematic underestimation of the opportunity cost of the time spent building. When you account for time fully — including the time to build, the time to maintain, and the time that elapsed while a challenger captured the market you were trying to capture — the build decision is almost never right for anything that is not a genuine core differentiator.

I have advised enterprises on this decision across multiple categories — platform infrastructure, capability gaps, channel expansion, data and analytics — and the pattern is consistent. The organizations that move fastest are clear-eyed about what is actually differentiating for their business and buy everything else. The organizations that move slowest are building commodity capabilities from scratch while their challengers are already deploying them.

The build bias isn't irrational.
It just doesn't account
for time correctly.

The psychological pull toward build in large organizations is driven by a set of factors that are individually reasonable. The technology team has capacity and wants to use it on interesting problems. Vendor dependency feels like a strategic risk, especially after a vendor relationship has gone badly in the past. The licensing cost of a vendor solution is visible in the budget; the cost of the engineer-years spent building is already accounted for as headcount. Custom builds can be tuned exactly to the organization's requirements; vendor products require compromise. Each of these is a real consideration.

The failure is in the accounting. When enterprises evaluate build vs. buy, they compare the annual licensing cost of a vendor solution against the direct costs of the build — engineering time, project management, QA. They rarely include the full opportunity cost of engineering time that could have been spent on genuinely differentiating work; the cost of the delay while the build is in progress; the ongoing maintenance cost of a custom build (15–25% of the initial build cost, annually, indefinitely); or the cost of keeping a custom build current as the technology evolves. When these costs are factored in, the break-even timeline for a custom build versus buying a vendor solution extends well beyond the planning horizon of the organization doing the analysis.

The build decision looks
cheap on year one.
It looks very different on year five.

Maintenance is the most consistently underestimated factor in build decisions. A custom-built system does not maintain itself. As the technology landscape evolves, the custom build needs to be updated to integrate with new systems, handle new data formats, comply with new regulations, and serve increasingly sophisticated user expectations. None of this work was budgeted when the decision was made to build, and all of it competes with the engineering capacity that the technology team would rather spend on new capability. The custom build that looked like a cost-saving decision in Year 1 becomes a constraint in Years 3–5 — paid for in engineering hours that can't go anywhere else.

Build is the right answer
in exactly the situations where
no vendor can serve you.

There are genuine cases where build is the right decision. They are narrower than most enterprises believe, but they are real. The test is a single question: is this capability genuinely differentiating for our business in a way that cannot be replicated by configuring a vendor solution?

When you buy a vendor solution,
you're not buying software.
You're buying accumulated learning.

The buy decision is often framed as purchasing functionality — the vendor's product does X, the organization needs X, so the organization buys the vendor's product. This framing undersells what is actually being acquired. A well-built vendor solution in an established category represents years of product development, customer feedback, integration work, and engineering refinement. The organization buying it is not just buying the current feature set — it is buying the organizational learning embedded in that product, at a fraction of the cost of generating that learning independently.

The evaluation criteria for the buy decision should go beyond feature comparison. The key questions are: does this vendor have genuine depth in the specific problem we're solving, or is this feature a horizontal addition to their primary product? What is the vendor's development velocity — is the product improving at a rate that keeps pace with our category? What does the integration ecosystem look like — can we connect this to our existing stack without building extensive custom plumbing? And what is the vendor's durability — will this company still be investing in this product in three years?

Partnership is the most
underexplored option — and
the most frequently misused.

The partner model — joint ventures, channel partnerships, capability-sharing agreements, strategic investments — is genuinely underexplored in enterprise commerce strategy. It is also, in its most common forms, not actually a strategic decision but a procurement outcome with relationship language applied to it. The distinction matters.

Real partnership — where two organizations bring complementary assets to a shared commercial objective, share both investment and return, and build the relationship over time — works when both parties have something the other genuinely needs and cannot easily acquire independently. A brand with distribution and a startup with technology is a classic genuine partnership structure. A brand that "partners" with an agency to outsource execution is not a partnership — it is a vendor relationship with better language.

The partner model works best in three specific commerce situations. First, channel expansion: when the organization wants to enter a channel where a specialist partner has established relationships and operating infrastructure that would take years to build. Second, capability access: when the capability required is genuinely emerging and the best way to access it is to invest in or partner with the startup building it, rather than waiting for the technology to mature to a level where it can be bought. Third, distribution scale: when the partner's customer reach provides a multiplication of the organization's own reach that cannot be replicated through any other means within the relevant timeframe.

The sequence matters as much
as the decision. Build-then-buy
is a different bet than buy-then-build.

One of the most important and least discussed dimensions of the build vs. buy decision is sequencing. The question is not always "should we build or buy this capability?" — sometimes it is "should we buy now and build later, or build now and potentially replace with a vendor solution when the market matures?"

Buy-then-build is the right sequence for most enterprise commerce capabilities. Use a vendor solution to move fast, learn what the capability actually requires in your specific context, and build the custom solution only when you have enough real-world operational data to know exactly what to build. The organizations that build custom solutions before they have operational experience in the capability consistently build the wrong thing. They discover what they actually needed only after deploying the custom solution — at which point they are either committed to maintaining a suboptimal system or facing a rebuild.

Build-then-buy is the right sequence in the narrow set of cases where the proprietary head start has genuine competitive value. If building a capability first gives you 18–24 months of operational data and customer learning that competitors cannot access, the build may justify itself through that advantage even if the ultimate solution is a vendor product or a rebuilt custom system. This is the exception, not the rule.

A framework for making
the build vs. buy decision
on first principles.

The framework below is the one I use when advising enterprise commerce teams on capability decisions. It starts from the differentiating question and sequences through the key evaluation criteria in an order that prevents the most common failure modes.

The build vs. buy vs. partner decision reduces, in most cases, to a question about honesty. Is this capability actually differentiating, or do we just prefer building it? Is the full cost of build being accounted for — time, opportunity cost, maintenance — or is the analysis only counting direct expenditure? Is the partner model being evaluated as a genuine strategic option, or dismissed because it does not fit the existing organizational model for how deals get done? The organizations that answer these questions straight — and make the decision on first principles rather than default preference — are the ones that move fastest and build the strongest commercial positions. The ones that default to build because it feels safer end up paying for yesterday's decisions while their challengers deploy tomorrow's capabilities.