Build vs Buy AI Product Content: The Hidden Costs

Picture the scene: a retailer has 5,000 unenriched products and a backlog that is growing every week. Someone in the room opens a ChatGPT tab, pastes in a product name and an image URL, and the model produces a competent description in three seconds. The room goes quiet. Then the question comes: “Why are we paying for a platform?”

It is a fair question. The answer is not “because AI is hard.” The answer is: that description is the least expensive part of what you are actually trying to build. The AI retail merchandising problem is not generating text. It is generating the right text, at scale, consistently, compliantly, and without requiring an engineer on call every time something changes.

What building in-house actually means

When someone in a planning meeting says “can’t we just build this ourselves?”, they are usually imagining writing a prompt and calling an API. That part takes an afternoon. What they are not imagining is everything else:

Applying your attribute schema consistently across every product category
Scoring output quality and routing exceptions for human review
Handling batch processing at catalogue scale without timeouts or partial failures
Managing model updates when your prompt stops working the way it did last month
Producing compliant, traceable output that satisfies the EU AI Act
Building a UI your merchandising team can use without opening a terminal
Having someone accountable when the developer who built it moves on

That is the actual scope of the project. The LLM API call is roughly 5% of it. The other 95% is what specialist platforms exist to solve.

The five hidden costs

Schema is the hard part, not the prompt

Generating a description is one API call. Getting it to consistently apply your schema (your taxonomy codes, your attribute names, your normalised size labels, your brand voice rules) is months of engineering.

A retailer with 20 product categories has 20 different schemas. Each one needs to be defined, tested, and maintained. When the schema changes (a new category is added, a new attribute is required, a supplier format changes), the prompt changes, and everything downstream needs to be retested. There is no automatic propagation. Someone has to find the failure, understand why it happened, and fix it without breaking the categories that were already working.

Specialist platforms encode this work into configurable schema blocks that your merchandising team manages without touching code. You can read how schema blocks define your attribute model in merchi.ai. The principle matters: schema should be a configuration problem, not an engineering problem.

Quality scoring and exception handling

A pipeline that enriches 5,000 products and silently gets 200 of them wrong is not a success. Attributes extracted incorrectly, descriptions that are plausible but factually wrong, taxonomy classifications that put a garden rug in “Flooring”. These are not edge cases. They are routine outputs from any LLM-based pipeline operating at scale.

A production system needs per-attribute confidence scoring, automatic flagging of low-confidence outputs, and a review workflow your team can action without logging into the codebase. None of this comes with the API key. Building it is weeks of work. Maintaining it is ongoing overhead that does not show up in the initial proposal.

Model updates break things

LLM providers update their models. Outputs change. Prompts that worked last month produce subtly different results this month. A small team running an internal tool will not notice until a category manager flags that the furniture descriptions have started including hallucinated dimensions, or the colour attributes are coming back in American English spelling.

Specialist platforms absorb model updates as part of their service. When a model is deprecated or its behaviour changes, the platform vendor investigates, adjusts, and tests. An internal tool makes every one of those updates your problem, on top of everything else your team is doing.

Compliance is not optional

The EU AI Act applies to AI-generated content published to EU consumers. The practical requirements include an audit trail of what model generated what output, human-in-the-loop review processes for certain content types, and documentation of the AI system used. The AI Provenance Protocol exists specifically to address this for product content, providing a standardised way to record and disclose AI involvement in published material.

A Codex project or an internal LLM wrapper does not include any of this by default. You either build it (more engineering) or accept the compliance risk. Neither option is free. The retailers we work with who have looked closely at the EU AI Act requirements typically conclude that compliance infrastructure alone would justify the cost of a specialist platform. Our own approach to this is covered in how the EU AI Act affects AI product content for retailers.

The developer becomes the permanent owner

The person who builds the tool owns it. Every schema change, every model deprecation, every bug report from the merchandising team, every new product category lands on them. This is one of the most consistent outcomes reported by teams who have gone this route. The tool works well until the person who built it leaves, and then it slowly degrades because no one else fully understands it.

A commercial platform has a support contract, an SLA, and a team whose entire job is making sure the system keeps working. That is not a trivial difference in a business where product content quality directly affects conversion.

When building in-house does make sense

To be direct about this: there are circumstances where an internal build is the right call.

It makes sense when the use case is genuinely bespoke and no commercial platform covers it. It makes sense when you have significant dedicated engineering capacity and the tool will be a product differentiator for your own customers. It makes sense when the volume is very low and the economics of a SaaS platform simply do not stack up.

What it does not make sense for is a retailer whose core competency is selling products, not building software. The relevant question is not “could we build this?” It is “should we be the ones maintaining this in two years?”

What a commercial platform gets you instead

The practical comparison comes down to time, consistency, and coverage.

With a specialist platform, the time from signed agreement to first enriched products is typically days, not months. The product data enrichment pipeline is already built, tested, and in production with other retailers. The schema tooling, the quality scoring, the exception handling, the compliance documentation: all of it is included. You configure it for your catalogue rather than building it from scratch.

Configurable schema means your merchandising team can update attribute definitions without raising a development ticket. Quality scoring means exceptions surface automatically. Support for 40-plus languages in the same pipeline run means international catalogue work does not require a separate project.

Grosvenor Flooring is worth naming directly. They had a 1,000-product backlog that was blocking their online growth. That backlog was cleared on the platform, descriptions and attributes enriched and published, contributing to 976% online revenue growth. The work was done on the platform, not by an internal engineering team, because they do not have one. You can read the full detail in the Grosvenor Flooring case study. The point is not that they are unusual. The point is that most retailers are in exactly this position: the need is real, the internal capacity is not there, and waiting to hire is not a growth strategy.

This is also what the AI product content retail tech stack picture looks like in practice: a specialist content platform that integrates with your PIM, your ecommerce platform, and your feeds. Not a custom build that your team has to maintain alongside everything else.

Should you build your own AI product content tool? For most retailers, the answer is no. The LLM call that generates a description is easy to write. The production system around it (schema management, quality scoring, exception handling, model update resilience, compliance documentation, and ongoing maintenance) is the actual product. Building that in-house requires engineering time, ongoing ownership, and a commitment that most retail teams are not resourced to sustain. A commercial platform delivers all of it from day one, at a cost that is almost always lower than the true fully-loaded cost of an internal build.

If you are evaluating whether to build or buy, book a call and we can run your own product data through the platform in the session, so you are comparing a real output, not a demo.

Or start a 30-day free trial today.

Frequently Asked Questions

Should I build my own AI product description generator?

For most retailers, no. Building a prompt that generates a product description is straightforward. Building a production pipeline that applies your schema consistently, scores output quality, handles exceptions, stays compliant with the EU AI Act, and keeps working when the underlying model changes is a substantially larger engineering project. Unless you have dedicated engineering capacity and the tool will be a genuine product differentiator, a commercial platform is almost always faster and cheaper on a fully-loaded cost basis.

What are the hidden costs of building AI product content in-house?

The five most common are: (1) schema definition and maintenance across every product category, (2) quality scoring and exception handling so errors surface before they reach the catalogue, (3) absorbing model updates when prompt behaviour changes, (4) building compliance infrastructure for the EU AI Act, and (5) the ongoing ownership cost when the developer who built the tool becomes its permanent maintainer. None of these appear in the initial estimate of “how long will it take to write the prompt.”

How long does it take to build a production AI product content pipeline?

A basic prototype (one prompt, one category, no quality scoring) can be built in a day. A production pipeline that handles multiple categories with different schemas, flags exceptions, processes at batch scale, and produces compliant output typically takes three to six months of engineering time. Ongoing maintenance adds to that indefinitely.

What is the difference between an LLM wrapper and a specialist AI product content platform?

An LLM wrapper calls an AI model and returns text. A specialist platform adds schema management so attributes are defined and applied consistently, quality scoring so low-confidence outputs are flagged rather than published, batch processing infrastructure, compliance documentation for regulatory requirements, and a user interface your merchandising team can operate without engineering support. The wrapper is the easy part. The platform is the rest of it.

Does the EU AI Act apply to AI-generated product descriptions?

Yes. AI-generated content published to EU consumers falls within scope of the EU AI Act. Practical requirements include maintaining an audit trail of what model generated what output, ensuring human review processes are in place for certain content types, and documenting the AI system used. Retailers using internal builds without compliance infrastructure face regulatory exposure. The AI Provenance Protocol provides a standardised approach to recording and disclosing AI involvement in product content. See also our full guide to the EU AI Act and AI product content for retailers.

How does merchi.ai handle model updates and schema changes?

Model updates are absorbed at the platform level. When a provider updates a model and output behaviour changes, the platform team investigates, adjusts prompts and configuration, and validates before releasing. Retailers are not exposed to model deprecation events. Schema changes are managed through the platform’s configuration interface: your team can update attribute definitions, add new categories, and adjust vocabulary without raising a development ticket.

What happens when the developer who built the internal tool leaves?

This is one of the most common failure modes for internal AI content tools. The developer who built the system holds the institutional knowledge of why it works the way it does. When they leave, schema changes and model updates become harder to manage, bug reports from the merchandising team have no obvious owner, and the system gradually degrades. A commercial platform has a support team and an SLA that does not depend on any individual. That continuity is part of what you are paying for.