AI-Powered Product Recommendations: Build vs Buy

Recommendation engines are the AI ecommerce category with the most mature vendor market and the most common build-vs-buy mistakes. Teams build them when they should have bought. Teams buy them when they should have built. The mistake costs are real on both sides — wasted engineering quarters on the build mistake, missed personalization revenue on the buy mistake.

This article is the decision rule. What off-the-shelf recommenders deliver, when custom builds earn their seat, and the cost math underneath both choices.

What recommendation engines actually do

In production, recommendation systems are mostly classical machine learning. Collaborative filtering (what users similar to you bought), content-based filtering (what's similar to what you've viewed), matrix factorization (latent feature models), and gradient-boosted scoring on top of those candidate generators. Sometimes deep learning for sequence modeling (recently viewed → next likely view) and embeddings (semantic product similarity).

The user-facing surfaces are familiar: "you might also like" on product pages, "frequently bought together" in cart, "recommended for you" on the homepage, post-purchase upsells in email, search-result ranking by personal relevance. Each surface has slightly different signals and different optimization targets — homepage recommendations optimize for engagement, cart recommendations for AOV, post-purchase for retention.

What's important to internalize: recommendation engines aren't LLMs. The 2026 frontier of LLMs hasn't displaced specialized recommender systems for the actual scoring layer because LLMs are too slow, too expensive per call, and not specifically trained on ranking objectives. LLMs increasingly show up at the interface layer (conversational shopping, query understanding) but the recommendations themselves are still classical ML.

The off-the-shelf vendor market in 2026

Four vendors dominate the mid-market and enterprise ecommerce recommendation space:

Algolia. Strongest as a search platform with recommendation features bolted on. Best fit if you already use or want Algolia for search. Pricing scales by indexed records and search volume.

Klevu. Built specifically for ecommerce, deep Shopify integration. Strong out-of-the-box performance for general merchandise and fashion. Pricing scales by catalog size and traffic tier.

Constructor. Strongest on attribute-aware search and recommendations, with explainable signals. Often picked by teams who need recommendations on technical or B2B catalogs.

Bloomreach. Enterprise-tier search and recommendation, often part of broader digital experience platform deployments.

Native platform recommenders also exist — Shopify's recommendation API, BigCommerce's native recommendations, Salesforce Commerce Einstein. These are usually weaker than dedicated vendors but free or low-cost as part of platform.

The vendors all use modern recommendation techniques under the hood. The differences customers feel are at the integration, configuration, and explainability layer rather than at raw ML quality.

When buying is the right answer

Three signals that point to buying:

Generic ecommerce catalog without proprietary signals. Apparel, home goods, electronics, beauty, general merchandise — categories where user clicks, purchases, and product attributes capture most of the relevant information. Vendors handle this exceedingly well.

Below 1M monthly active visitors. The data volume isn't large enough to train custom models that meaningfully outperform vendor models. The break-even on custom development is rarely justified at this scale.

Engineering team smaller than 20 people. Custom recommendation systems require dedicated ML engineering, data engineering, and ongoing maintenance. Below 20-person engineering teams, the opportunity cost of pulling people onto recommendations usually beats the marginal performance gain.

For these cases, an Algolia or Klevu deployment gets you 80-90% of the recommendation revenue capture in 4-8 weeks of integration work, with vendor pricing in the $30K-150K annual range for mid-market traffic. The math works.

When building is the right answer

Three signals that point to building:

Proprietary data signals off-the-shelf engines can't model. Subscription history (cohort effects, retention dynamics). B2B account-level dynamics (multi-buyer organizations, RFP-style purchasing). Regulatory filters (medical device certifications, region-specific availability). Niche category structures (luxury authentication, specific industrial taxonomies). When the data that matters most for relevance isn't in any vendor's standard schema, custom modeling earns its seat.

Above 1M monthly active visitors and a serious ML team. At this scale, the data volume supports custom training and the team supports custom maintenance. The break-even tilts toward building.

Strategic differentiation through personalization. Some businesses (Amazon, Netflix, Spotify) treat recommendations as core competitive advantage and invest accordingly. For most ecommerce, recommendations are a feature, not a moat. But for businesses where it's a moat, building makes sense.

For these cases, custom recommendation systems usually take 6-12 months for an initial build and require a dedicated team of 3-5 ML and data engineers ongoing. Build cost: $1-3M in the first year, $500K-1.5M per year ongoing. Justified only at scales where it pays back.

The cost math, side by side

For a mid-market ecommerce business with $50M annual revenue and 500K monthly active visitors:

Buy (Klevu or Algolia mid-tier):

• Annual platform: $60K-120K
• Integration build: $30K-80K (one-time)
• Ongoing engineering: ~0.5 FTE
• Time to launch: 6-12 weeks

Build (custom on AWS or GCP):

• ML team: 2-3 FTE for build, 1-2 FTE ongoing
• Cloud compute: $20K-60K annually
• Data engineering: significant portion of existing data team
• Time to launch: 4-9 months

The buy version costs roughly $200-300K in year one, all-in. The build version costs $600K-1.2M in year one. For most mid-market businesses, the buy version captures 80-90% of the recommendation revenue lift at 25-40% of the cost.

The build version becomes worthwhile when the proprietary signals justify it OR when you've grown past the scale where vendor pricing scales linearly with traffic.

The hybrid pattern many teams converge on

The most common production pattern for businesses that outgrow vanilla off-the-shelf recommendations: keep the vendor for general recommendations, build custom for specific high-value surfaces. Buy Algolia or Klevu for product page "you might also like." Build custom for the homepage hero personalization or the post-purchase email recommendations, where proprietary cohort and lifetime-value signals materially change the ranking.

This hybrid keeps the engineering team focused on the highest-leverage 10-20% of the recommendation surface area while paying the vendor to handle the other 80-90%. It's the pattern that scales sensibly from $50M to $500M ecommerce businesses.

Where LLMs fit (and don't)

Two LLM-adjacent patterns are showing up in 2026 ecommerce recommendations:

Conversational shopping interfaces. A user types "I need a waterproof jacket for hiking, budget $200, prefer sustainable materials." An LLM parses this into a structured query and feeds it to the recommendation engine. The actual ranking is still classical ML; the LLM handles the interface translation.

Query understanding for search. LLMs translate ambiguous or natural-language search queries into structured filter sets that traditional search and recommendation systems can act on. Same pattern: LLM at the interface, classical ML at the ranking.

Don't put an LLM in the recommendation scoring loop. Cost, latency, and ranking quality all favor specialized models. The LLM is the new top-of-funnel; the recommender is the working engine.

What to do this week

If you're staring at a recommendation project on the roadmap, three steps before any build commitment.

One. Run a 4-week pilot with a top-tier vendor on your real traffic. Algolia, Klevu, Constructor — pick whichever fits your platform. Measure the actual revenue lift on the surfaces you care about.

Two. If the lift hits 80% of what you needed, ship the vendor version and use the engineering capacity for higher-leverage work. Most mid-market businesses stop here.

Three. If the lift falls short and you can identify why (specific signals the vendor can't model, specific surfaces where proprietary data matters), then build for those gaps while keeping the vendor for the general case. The hybrid pattern usually wins.

The teams who skip the pilot and commit to a custom build first usually end up rebuilding the same off-the-shelf capabilities the vendor would have shipped. The teams who commit to vendor-only and never invest in proprietary surfaces leave personalization revenue on the table at scale. Pick the right side of the line. Re-evaluate yearly. The right answer can change as you grow.