Content at catalogue scale, with the checks that make it safe

What this actually solves

There is a specific kind of stuck that brings people to this page. A catalogue has thousands of products and half of them carry the supplier's copy-pasted description, which is the same text sitting on twenty competitors' sites and which persuades nobody. Or there are a hundred service-and-location combinations that each deserve a real page and there is one marketing person. The work is not difficult. It is just large, and being large is what makes it never happen — it goes on a list, someone does forty of them, and the list stays.

Commissioning it out by the piece prices the problem out of existence. The rate is fine for twenty pages and absurd for thousands, and the calendar is worse than the cost — a queue that long finishes in years, by which time the catalogue has turned over. So the pages stay thin, they rank for nothing, and the shop competes on price because there is nothing else on the page to compete with.

What a pipeline changes is the unit of work. Instead of commissioning pieces you commission a system: a voice specification, a structure per content type, your own product data as the raw material, and a set of checks that every output has to survive. Once it exists, the marginal cost of the next thousand pages is small, and — more usefully — regenerating everything when the brand voice changes or the product data improves becomes a job you run overnight rather than a project you re-fund.

How the work runs

1. Extract the voice from what you already have. Your best existing content, read and turned into a specification — register, sentence rhythm, the claims you make, the claims you never make, and an explicit banned-word list. Every category has words its buyers distrust, and a brand that sells to people who actually use the products usually has strong opinions about them. Three to five days.
2. Define the output structure per content type. Exactly what a piece consists of — a short summary, a longer body, a fixed number of feature bullets, a meta description under 155 characters — so that output is checkable rather than merely readable. Two to four days.
3. Wire in the real data. Product attributes, specifications, pricing, categories, review text where it exists, keyword research where it is in scope. This is the step that decides whether the output is informative or generic, and it is where most of the difference between a good pipeline and a bad one is created. Three to five days.
4. Build the pipeline itself. Batched execution that resumes from where it stopped rather than starting the whole run again, per-batch cost logging, and a content register in Airtable or Sheets so the state of every piece is visible. Three to five days.
5. Write the quality control checks in code. Length within range, required structure present, banned words absent, keyword present where required, near-duplicate detection across the whole set, and the attribute check that compares each claim against the source fields. Failures are routed back for regeneration or to a person, never published. Four to six days.
6. Pilot batch, human sample, calibration. A limited run reviewed by a person against a sample size chosen to represent the batch, with the findings fed back into the voice specification and the checks before the volume run is authorised. Three to five days.
7. Full run and publishing. Execution in batches with the register updated as it goes, then publication through the CMS API or as import files. Two to five days.

What moves the price

The range is $1,000–$10,000 over 2–6 weeks, with model usage billed on top and estimated before the full run. Three things decide the build fee.

Volume and the number of content types. One template across five thousand products is a different build from six templates across a few hundred pages each. Each content type needs its own structure, its own checks and its own review pass, so types cost more than units.

Whether research is inside the scope. Generating from data you already hold is the cheaper path. Adding keyword research, competitor analysis and search-intent mapping so the pipeline knows what each page should be trying to rank for is genuine additional work sitting in front of the generation.

Where it has to publish, and whether editing is included. A CSV handover is simple; a direct CMS integration with staged drafts, image handling and scheduling is not. And human line editing of every piece, if you want it, is a separate service priced separately — worth saying plainly, because it is usually the largest optional line.

What usually goes wrong

The whole batch ships because the first ten read well. Output is skimmed, it looks convincing, and thousands of pieces go live. Weeks later someone notices a set of descriptions claiming a feature the product does not have — waterproofing that is only water-resistant, a size that is not stocked — because the model filled a gap in the input using what is typical for the category. Returns follow, and so does the reputational damage that is far more expensive than the pipeline was. Every batch gets a sampled human read, and the sample is sized rather than guessed.

The fact-check is written into the prompt instead of into the code. Telling the model to use only the supplied specifications is a reasonable instruction and it works most of the time, which is exactly what makes it dangerous. The failures are a small, invisible fraction spread across thousands of pieces. The check that catches them is programmatic — take each factual claim in the output, look for it in the input fields, reject the piece if it is not there.

Nobody checks the set against itself. Two colourways of the same jacket, four sizes of the same tent, twelve towns within the same county — generated independently, these come out near-identical, and a catalogue of interchangeable text is the exact thing that gets treated as low value. Similarity comparison across the full output set, with regeneration of the clusters it finds, is a step in the pipeline rather than a thing to check for afterwards.