Build vs buy vs partner for luxury AI

# Build vs partner vs buy for luxury AI

A creative director at a European leather goods maison wants visual search: a customer photographs a stranger's bag on the street, uploads it, and the app finds the closest match in the maison's current collection. The technology exists. The question that actually determines success isn't "can we build this," it's "should we build it, buy it, or plug into someone else's."

This is the single most consequential AI decision most luxury executives will make this decade, and it gets made badly because teams default to whichever option the loudest vendor or the most confident engineer pitches first.

Three paths, one recurring mistake

Build: an in-house team develops the model, owns the code, controls the roadmap. Chanel's internal data science efforts and LVMH's investment in proprietary AI tooling (via its LVMH Innovation Award and internal "Brand Ferrari" style incubators, as reported in luxury trade press) sit here.

Buy (license): you pay a vendor for a packaged solution. Fashion-tech vendors like Heuritech (trend forecasting), Lalaland.ai (AI-generated model imagery), or Vue.ai (visual merchandising and search) sell subscription access to models they trained, often on cross-brand data.

Partner: you integrate with a platform that already has the audience, infrastructure, and often the AI layer built in. Farfetch's Platform Solutions business, or Alibaba's Luxury Pavilion, are examples where a maison plugs into someone else's stack rather than owning or licensing a standalone tool.

The recurring mistake: treating this as a procurement decision (cost, speed, vendor reputation) when it's actually a strategic control decision. The right frame has three axes.

The decision framework: three axes that matter more than price

1. Brand control

Does the AI touch anything customer-facing that carries brand voice, image, or aesthetic judgment? Visual merchandising, styling recommendations, chatbot tone, generated imagery: all of these are brand expressions, not just features.

High brand-control-sensitivity tasks (a virtual try-on that must render fabric drape exactly as the ateliers intend) push toward build or a tightly customized buy, because a shared vendor model trained across many brands will regress to a generic aesthetic middle.

Low sensitivity tasks (fraud detection on payment transactions, warehouse inventory forecasting) don't touch the brand at all. Partner or buy freely.

2. Data ownership

Who keeps the customer interaction data, the images, the purchase signals generated by the AI system?

This matters for two reasons. First, competitive: if a maison's customer behavior data trains a vendor's shared model, that data may indirectly improve a competitor's results too, since many fashion-tech vendors serve multiple brands in the same category. Second, regulatory: under the EU's GDPR (General Data Protection Regulation) and similar frameworks, contracts must specify who is the "data controller" (the entity deciding how data is used) versus the "data processor" (the entity handling it on the controller's behalf). Partnering with a large platform like Farfetch typically makes the platform a joint controller for shared customer data, a materially different legal and strategic position than a pure licensing deal where the maison usually retains control.

Ask concretely: if we exit this vendor tomorrow, do we walk away with the trained model, the raw data, both, or neither? Most vendor contracts, if unexamined, give you neither.

3. Reversibility

How expensive and slow is it to unwind this choice in two years if it underperforms or a better option emerges?

Build is slow to start but highly reversible in the sense that you own everything; you can pivot the model without renegotiating anyone's contract. Partner is fast to start but often the least reversible: once a maison's catalog, pricing, and customer relationships are embedded in a platform's ecosystem (Farfetch, Tmall Luxury Pavilion), migrating out means rebuilding distribution, not just swapping software. Buy sits in the middle: switching vendors is usually contractually possible but operationally disruptive (re-integration, retraining staff, data migration).

A simple weighted scoring exercise

Score each option 1 to 5 on each axis, then weight by what matters most for the specific use case. Here's a worked example for the visual search tool from the opening scene.

| Axis | Weight | Build | Buy (vendor) | Partner (platform) |

|---|---|---|---|---|

| Brand control | 0.4 | 5 | 3 | 2 |

| Data ownership | 0.35 | 5 | 3 | 1 |

| Reversibility | 0.25 | 4 | 3 | 2 |

| Weighted score | | 4.65 | 3.00 | 1.65 |

Calculation for Build: (5 × 0.4) + (5 × 0.35) + (4 × 0.25) = 2.0 + 1.75 + 1.0 = 4.65.

This scoring is illustrative, not a universal answer: weights should shift by use case. For a back-office task like demand forecasting, brand control weight drops toward 0.1 and cost/speed considerations rise, often flipping the outcome toward buy or partner.

Where the calculus flips: cost, speed, and talent

The framework above deliberately excludes upfront cost, but it can't be ignored entirely. Building genuinely capable computer vision or generative AI systems in-house requires machine learning engineers, annotated training data, and ongoing compute costs, resources most maisons (even large ones) don't have in-house at the depth that pure tech companies do. Google's guide to responsible AI practices is a useful free reference for what "genuinely capable" internal AI governance requires operationally, useful before committing to build.

This is why even LVMH and Kering, groups with real balance sheets, still license specialized vendors for narrow tasks (trend forecasting, counterfeit detection) rather than building everything internally. Build makes sense for the few capabilities that are genuinely brand-differentiating and durable. For everything else, buy or partner is usually more rational, not a compromise.

Applying the framework: three quick scenarios

Scenario A: a maison wants a customer service chatbot handling order status queries. Low brand sensitivity (functional, not aesthetic), moderate data concerns (order data is sensitive but not proprietary-model-defining), high reversibility need (chatbot vendors are commoditized). Verdict: buy.

Scenario B: a maison wants an AI system that recommends which fabrics and cuts to produce next season, trained on the house's own archive and sales history. High brand control (this is core creative judgment), high data ownership stakes (this is the house's design IP), low reversibility tolerance (getting it wrong damages the collection, not just a feature). Verdict: build, or at minimum a heavily customized, exclusively-licensed model where the maison owns outputs.

Scenario C: a maison wants presence on a major Asian marketplace's AI-curated recommendation engine to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → new customers. Low brand control over the algorithm itself (you don't control Alibaba's or Farfetch's recommendation logic), genuine data-sharing trade-offs, low reversibility once integrated. Verdict: partner, but negotiate data terms explicitly before signing, and treat it as a distribution decision as much as a technology one.

🎬 [VIDEO: "Build vs Buy: The Innovator's Dilemma for AI" - youtube.com - search for recent talks from MIT Sloan or Harvard Business Review on AI make-or-buy decisions in retail and consumer brands, applicable directly to luxury]