The default for most enterprise commerce decisions should be buy or partner first, build only for genuine differentiators. In practice organizations choose build around 70 percent of the time, and the economics rarely support it.
- A custom build replacing a $150K-a-year vendor typically costs $1M to $3M to build and $200K to $500K a year to maintain.
- Add 18 to 36 months of lost market timing and the buy decision wins in almost every non-differentiating category.
- The fastest organizations are clear about what is differentiating and buy everything else.
The default answer for most enterprise commerce decisions should be: buy or partner first, build only for genuine differentiators. That sounds obvious. But in practice, large organizations choose build roughly 70% of the time, and the economics rarely support it. A custom build that replaces a $150K/year vendor solution typically costs $1M–$3M to build and $200K–$500K per year to maintain. Add 18–36 months of market timing loss and the full opportunity cost of engineering time, and the buy decision wins in almost every non-differentiating category. This post lays out the framework for knowing which is which.
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. It is the same dynamic that turns a legacy commerce platform into the bottleneck the organization can no longer ship around.
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 bias doesn't account for time correctly. The opportunity cost of 18 months spent building is almost always larger than the lifetime licensing cost of the vendor solution you could have bought."
The build decision looks
cheap on year one.
It looks very different on year five.
| Cost Category | Custom Build (5-year) | Vendor Buy (5-year) | Notes |
|---|---|---|---|
Initial Cost |
$500K–$2M+ in engineer-years | $50K–$200K implementation | Build initial cost is often underestimated by 40–60% |
Annual Licensing |
$0 (appears) | $50K–$500K / year | Licensing is visible. Build maintenance is not. |
Annual Maintenance |
15–25% of build cost / year | Included in license | Custom build maintenance is rarely budgeted in year 1 |
Opportunity Cost |
High, engineers building this can't build differentiating work | Low, vendor builds it, your engineers build differentiation | Rarely quantified. Usually the most significant cost. |
Time to Deploy |
18–36 months | 4–12 weeks | Market timing cost of 18-month delay is rarely modeled |
5-Year Total (typical) |
$3M–$8M fully loaded | $500K–$2.5M fully loaded | Variance is large; point is that build is rarely cheaper |
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?
Enterprise procurement processes are optimized for cost reduction, not vendor quality. The standard procurement dynamic (competitive RFP, multi-vendor evaluation, price negotiation) produces vendor selections that systematically underweight the factors that actually determine long-term value: product quality, development velocity, customer success track record, and cultural fit between the vendor's operating style and the enterprise's operating needs.
The organizations that make the best vendor selections are the ones that spend time talking to existing customers, testing the product in a real use case before signing, and evaluating the vendor team's responsiveness and depth of knowledge, not just their price. Enterprise procurement rarely allows time for this, which is why so many enterprise vendor relationships underperform their initial projections.
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.
I advise enterprise commerce teams on build, buy, and partner decisions. Early Shopify employee, operator across multiple categories, Fortune 500 advisor. The form takes two minutes.
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.
Frequently asked
questions.
The test is whether a competitor buying the same vendor solution would have equivalent capability. If the answer is yes, the capability is commodity, and commodity capabilities should almost never be built from scratch. The genuinely differentiating layer is almost always thin: proprietary data you have that a vendor cannot replicate, proprietary algorithms tuned to your specific customer behavior, or integration logic unique to your operating model. Everything else is infrastructure, and infrastructure should be bought. For a deeper look at how enterprise teams get this wrong, see Corporate Innovation: Theater vs Real.
80% is the threshold I use in practice. If a vendor solution covers 80% or more of the functional requirement, buy it and accept the remaining gap. The cost of building a full custom solution to close the last 20% typically exceeds the cost of the vendor solution over five years, and the remaining gap is almost never competitively significant. The organizations that build custom solutions to close the 20% gap consistently discover after deployment that the gap they closed was not the constraint they thought it was. What they actually needed was faster deployment, which the vendor solution would have provided.
The partner model earns its place in three specific situations. First, channel expansion where the partner already has established relationships and infrastructure in a channel you want to enter (building that from scratch would take years). Second, emerging capabilities where the vendor market is immature and investing in or partnering with the startup building the technology gives you earlier, better access than buying from a mature vendor. Third, distribution scale where the partner's reach multiplies your own in ways you cannot replicate internally. Outside those three contexts, what gets called a "partnership" is usually a vendor relationship with nicer language. The structural difference is whether both parties bring something the other cannot easily acquire independently, and share in both the investment and the return. See also why enterprise brands keep losing to DTC challengers, which often comes down to agility in exactly this kind of decision.
This is the most politically difficult question in enterprise technology: when to admit that a past build decision was wrong and transition to a vendor solution. The right answer is almost always "sooner than feels comfortable." Every year you maintain a suboptimal custom build is a year of engineering cost, a year of maintenance drag on future development, and a year where a better vendor solution is improving and your custom solution is not. The sunk cost of the original build is not a reason to keep paying operational cost. Model the transition cost honestly, include the cost of migration, retraining, and the vendor onboarding period, and compare it to three more years of the current maintenance burden. In most cases the transition wins on a 12–18 month payback horizon.
Shopify is the clearest current example of the buy decision playing out correctly at enterprise scale. The brands that adopted Shopify as a buy decision (rather than building a custom commerce stack) consistently reached full operational capability in 3–6 months versus 18–36 months for custom builds. The enterprise lab pattern takes this further: running Shopify as a parallel experimentation layer alongside the legacy stack lets brands access vendor capability without committing to full migration. They buy the vendor advantage, test in real conditions, and migrate the proven use cases. It is the buy-then-build sequence applied to platform decisions, and it consistently outperforms the full-rebuild approach. For the full enterprise commerce decision landscape, see What Shopify Taught Enterprise Commerce.
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.
The build, buy, or partner decision in commerce rarely has an obvious answer, which is exactly why the enterprise innovation practice exists. When you are weighing yours, start here.
Enterprise commerce strategy.
I advise Fortune 500 commerce teams on build, buy, and partner decisions across platform infrastructure, capability gaps, and channel expansion. I've seen the same mistakes repeat. The form takes two minutes.
Start a conversation More about Taylor →