The build-versus-buy question rarely gets the rigour it deserves. Engineering-led teams drift toward building because it is interesting; commercially cautious teams default to buying because it feels safe. Both shortcuts produce regret. The better approach is a deliberate decision per capability, judged on how much the capability differentiates you and how mature the market for it has become.
Why the default answers are wrong
“Build everything” assumes your team can match the focus of vendors whose entire business is one capability, and that you want to own the maintenance forever. “Buy everything” assumes there is always a good product for what you need and that being identical to your competitors is acceptable. Neither holds across the board. The right answer is almost always a mix, decided capability by capability rather than as a blanket policy.
The two questions that decide it
For any AI capability, ask two things before anything else.
1. Is this a differentiator or a commodity?
A differentiator is something where doing it better than rivals wins you customers or margin. A commodity is table stakes: necessary, but not a reason anyone chooses you. Order-status automation is a commodity; almost every store needs it and nobody picks you because yours is marginally better. A guided-selling experience tuned to a genuinely complex catalogue can be a differentiator, because the quality of the recommendation directly affects whether the shopper buys and keeps the product.
2. Is the market mature?
For some capabilities, excellent off-the-shelf products exist and improve faster than you ever could. For others, the products are immature, generic, or a poor fit for your stack and data. Maturity changes over time, so a “buy” that was wrong two years ago may be right today.
Combining the two gives a simple guide:
- Commodity and mature market → buy. Do not build a worse version of a solved problem.
- Differentiator and immature market → build (or heavily customise). This is where ownership pays off.
- Differentiator and mature market → buy a strong platform and invest your effort in configuration, data and tuning rather than the engine itself.
- Commodity and immature market → buy the least-bad option and revisit, or wait. Building here is usually a distraction.
What “build” and “buy” really cost
The headline price tag is the least of it. Compare total cost of ownership honestly.
Buying typically means faster time to value, predictable subscription costs, a vendor maintaining and improving the model, and shared learning across their customer base. The trade-offs are recurring fees that scale with usage, limited control over the roadmap, integration constraints, and the strategic risk of depending on a third party for something core.
Building gives you control, a capability shaped exactly to your data and workflows, no per-seat or per-transaction fees, and IP you own. The trade-offs are large and persistent: the build cost is only the beginning, and ongoing maintenance, monitoring, retraining, security and the specialist hiring to support it often dwarf it. Many teams budget for the build and forget the decade of upkeep.
A useful rule of thumb from our experience: the visible build cost is usually a fraction of the lifetime cost. If a build only just beats buy on the initial estimate, buy.
A scoring approach you can defend
To take the emotion out of it, score each candidate capability on a short rubric:
- Differentiation — does doing this better win customers? (low/medium/high)
- Market maturity — are there strong products that fit our stack? (low/medium/high)
- Data dependency — does it need proprietary data only we hold? (favours build/customise)
- Speed to value — how soon do we need it live? (urgency favours buy)
- Internal capability — do we have, and want to keep, the skills to run it?
- Switching cost — how locked in would a vendor choice make us?
Capabilities that score high on differentiation, high on data dependency and low on market maturity are your build candidates. Almost everything else points to buy or to a buy-and-configure middle path. This rubric slots directly into your wider eCommerce AI roadmap, where each initiative should carry a build/buy decision alongside its value estimate.
The middle path most teams underuse
The framing is rarely a clean binary. The most pragmatic option is often buy the platform, build the differentiation on top. Use a mature vendor for the heavy engineering, then invest your scarce effort in the data, configuration and domain logic that make it yours. A semantic search or recommendation engine is a good example: building the vector infrastructure from scratch is rarely worth it, but the merchandising rules, synonym handling and relevance tuning on top are where you win. Our notes on AI merchandising control and the wider AI search and recommendations work describe this layer.
This middle path captures most of the upside of building (a capability shaped to you) with most of the safety of buying (someone else maintains the engine).
Choosing a vendor without regret
When you do buy, the decision you will most regret in eighteen months is usually the vendor relationship, not the technology. Weigh:
- Data portability and lock-in. Can you export your data and configuration and leave? Lock-in is the hidden price of a cheap subscription.
- Roadmap alignment. Is the vendor heading where you need to go?
- Integration with your stack and your governance requirements, including where data is processed.
- Viability. A brilliant product from a fragile company is a liability.
Our guide to choosing an AI vendor partner goes deeper on due diligence.
Common pitfalls
- Building for prestige. “We’re an engineering company” is not a business case.
- Buying without an exit. If you cannot leave cheaply, you have not bought a tool, you have acquired a dependency.
- Ignoring lifetime cost. Maintenance, monitoring and retraining outlive the build budget.
- Treating the decision as permanent. Markets mature; revisit build/buy calls every year or two.
- Blanket policies. “Always buy” and “always build” are both wrong somewhere in your stack.
Where this leads
The build-versus-buy decision is not about technology preference. It is about being clear-eyed on what genuinely differentiates your store, how mature the market is for each capability, and what the full lifetime cost really is. Decide capability by capability, lean on the middle path more than you expect to, and revisit your calls as the market moves.
If you would like an independent view on which capabilities to build, buy or configure, our AI strategy team helps online retailers make these calls without the in-house bias. Talk to us before you commit to a long contract or a long build.