Putting a language model where a mistake would be public

Two requests that turned out to be one app

The first request was ordinary and constant: a catalog imported from a supplier feed, every product carrying two lines of specification and no meta description, and nobody with the weeks it would take to fix by hand. The second came from a client whose customers browse with their hands full, and who asked whether a product page could simply read itself out.

They share a spine. Both need a dependable summary of a product, written in the store's language and in the store's voice. So we built one generation layer and gave it two outputs: text that goes into Shopify fields after a human approves it, and a spoken summary the storefront can play on demand.

Six things we had to solve before shipping it

Anything built on a model provider fails in ways ordinary software does not. Most of this list exists because of that.

1. A model answer is not trusted input

   Every generation is forced through a declared response shape rather than parsed out of free text, and every field has a hand-written fallback behind it. If the model returns something unusable, the merchant gets a plain, correct sentence built from the product data instead of an error or, worse, nonsense written into a live product.

2. Pinned model versions rot underneath you

   A specific model identifier we had pinned began answering with a not-available error in production, with nothing changed on our side, while still being listed as available. We moved both quality tiers onto the provider's rolling aliases, so the app tracks whatever is currently served at that tier instead of breaking silently the next time a version is retired.

3. Rules the copy is never allowed to break

   Generated text may never state a price. Prices go stale the moment a merchant edits one, and under multi-currency selling the figure baked into a description is simply wrong for most of the audience. The same guardrail layer carries the house style rules and a language table, so the store's locale becomes a named language in the instruction rather than a code the model has to guess at.

4. Bulk work that resumes instead of restarting

   A thousand-product run is processed as bounded batches, with the count of finished items acting as the cursor, so a restart mid-run never redoes committed work or double-spends a merchant's allowance. Jobs left running by a crash are reclaimed, and a job whose store uninstalled during the run fails once and terminally rather than looping forever.

5. A voice with no audio pipeline

   The storefront reads aloud through the browser's own speech engine, so there are no audio files to generate, store, serve or pay for. The widget arrives as a theme app extension, no theme code is edited to install it, and it asks the app whether narration is actually available before it renders, so a shopper is never shown a button that would do nothing when pressed.

6. Fail open, or fail closed, on purpose

   Each fallback direction was chosen rather than defaulted. If the availability check cannot reach us the button stays visible, because hiding a working feature over one dropped request is the worse outcome. Attribution is the opposite: removing it is a paid entitlement, so the widget confirms that with the server and keeps the credit if the answer does not arrive.

What we can add to a store you already have

If you are considering an AI feature on a real storefront, the interesting questions are the ones above. What happens when the provider answers badly, or slowly, or not at all. Who approves the output before a customer reads it. How a long job survives a deploy. How a new element reaches the storefront without a developer editing theme files every time it changes. We answered all of those in production here, on our own name, before proposing any of it to a client.

What the app does, in short

• Writes descriptions, titles, meta descriptions, alt text and tags in bulk, in the store's own language and tone
• Scans the catalog for missing content so the gaps are visible before anything is generated
• Holds everything in review, so a person edits and approves, and any change can be reverted
• Adds a storefront Listen button through a theme app extension that plays in the browser
• Uses product data only, with no access to customer or order records

Full detail, every screen and the plans are on the Miko AI Descriptions & Narrate product page, and the merchant guide is at miko.co.nz/docs/narrate/.

Two screens that show the shape of it

One faces the shopper and has to be unremarkable. One faces the merchant and has to make a large change feel small.