A question that comes up constantly, and the answer changed while everyone was still panicking about it. The UKCA cliff-edge did not happen. CE recognition for Great Britain was extended indefinitely across the regulations that cover most consumer goods, including electrical safety, EMC, RoHS and radio equipment. UKCA is still valid. For the GB market you can use either. Three places that is not true: Northern Ireland follows EU rules, so UKCA on its own is not valid there. The EU needs CE. A UKCA mark does nothing at Rotterdam. A short list of categories sits outside the indefinite recognition, construction products and medical devices among them. Check your own category rather than assume. The part I wish someone had told me earlier is that the mark is rarely what costs you. These are the lines that arrive after the quote: Test reports per standard and per variant. EMC, electrical safety, RoHS, and radio testing if there is Bluetooth or Wi-Fi inside. A Bluetooth SIG qualification if the product pairs with a phone. Separate scheme, separate fee. A retest every time the factory swaps a component without telling you. This is the recurring one. A UK Responsible Person, and a second Authorised Representative if you sell into the EU as well. Two retainers, two addresses on the label. WEEE, packaging and battery registration, country by country rather than once. New label artwork, because every item above changes what the label has to say. We carry this stack on our own products, so none of this is theoretical. The honest lesson is that the first quote covers the mark, and the running cost is everything behind it. Budget year two, not just the first container. If you have been through a UKCA or CE process, what caught you out that was not in the quote? I will answer everything in the comments. One considered email a week on running an e-commerce company solo, plus two free guides when you join: https://www.puniverse.net/free?src=skool&utm_source=skool&utm_medium=community&utm_campaign=weekly_letter_evergreen&utm_content=daily-2026-08-02

Gold Earth is a small-batch skincare brand in Wiltshire. Eight products between £38.99 and £160, a Vegan Beauty Award, CPSR safety certification on every product. Real credentials, real formulation work. None of it was reaching Google. She came to us from a cold email. Not a pitch — a free read-only audit of her own storefront, no credentials, nothing touched. It scored 71 out of 100 with five findings. The one that mattered most: no product schema on any product page, so her prices and review stars never reached search results at all. No Organization schema either, so the brand was a string of text rather than an entity a knowledge graph could hold. She replied. She became our first paying services client. The rebuilt store went live on 29 July, and we re-ran the same crawl this morning: 100 out of 100, zero findings. What that took, in ten working days: - Six page types rebuilt, everything still editable in Shopify's normal editor afterwards. No developer needed to change a headline. - All five audit findings closed. Product and Offer schema with price and availability on all eight products, FAQPage schema, Organization and WebSite schema, llms.txt and agents.md. - Forty product photographs, shot from her own bottles so the labels are correct. - A compliance pass most people skip: under the UK Cosmetics Regulation a cosmetic cannot claim to treat a condition, and a testimonial cannot carry a claim the brand could not make itself. We scanned 4,063 sentences across products and collections. Her own story stayed; the claims that would not survive scrutiny went. - Zero minutes of downtime. Everything was built on a duplicate of the live theme and published in one switch. Two honest things, because a case study without them is advertising. First, the score is our own audit tool marking our own work. Take the checklist rather than the number: open any product page, view source, search for application/ld+json, and see whether a price is genuinely in there. On most stores it is not. That check costs you ten minutes and no tools.

This one costs people money quietly, so it is worth walking through properly. Google Merchant Center flags "missing barcode" (missing GTIN) across a catalogue and the instinct is to go hunting for numbers. On our store that warning covered 899 of 1,016 products. For most of them there was no number to hunt for. A GTIN is issued by GS1 to whoever owns the brand. Nobody else can issue one for you. That single fact splits the warning into three different problems. 1. A real GTIN exists. Branded goods, registered by the manufacturer. The number goes in Shopify's barcode field, which is what the Google feed reads as gtin. If you sell branded goods, never declare the identifier absent — Google can tell, and it looks like you are hiding something. 2. No GTIN was ever issued. Handcrafted, unbranded, white-label, own-design goods sourced from a factory that never registered anything. There is no barcode today and there never will be. Google's own answer here is a declaration rather than a number: identifier_exists = false. In Shopify that is the metafield mm-google-shopping.custom_product = true on the product. It says the identifier does not exist, instead of saying you failed to supply it, and the warning clears. 3. There are junk digits in the field. Somebody typed placeholder numbers at some point to make a validation error go away. This is the worst of the three. A GTIN carries a check digit, so an invalid one can be proven wrong, while an empty field is only a warning. On a client catalogue of eight handcrafted products we found five of these and cleared them before declaring anything. The sequence that works: 1. Export every product with its barcode field. Do not guess from memory. 2. Sort each product into one of the three states above. 3. Clear the junk values first, so nothing invalid survives into the feed. 4. Set the metafield on everything in state two, in bulk. 5. Where a supplier genuinely does provide a real EAN, put that in instead — a real identifier always beats a declaration.

I want to walk through a mistake I made, because it is easy to make and it costs money. The question was simple: two AI image models, one free to run, one costs credits per generation. Is the paid one worth paying for? So I benchmarked it. Product briefs, both models, score the outputs. The first pilot gave the paid model an 8-point lead. A second pilot agreed. Two runs, same direction, margin well outside noise. Normally that is where a benchmark stops. The flaw Both models received the same prompt. That sounds like rigour. It is the fair-test instinct: change one variable, hold everything else constant. But a prompt is not a neutral input. It is an interface. These two models do not read the same way — one wants a densely specified scene, the other wants a structured brief that separates product facts from scene intent. My prompts had been written over months by someone iterating against one model's failure modes. They were tuned. Just not for both. So I was not measuring which model was better. I was measuring which model happened to suit a prompt written for something else. The rerun Each model got its own template, carrying the same underlying product facts. Four categories, sixteen briefs, 32 generations, scored out of 200 per pick. Totals: 738 versus 759. An average gap of 1.3 points. Eight points became 1.3. Almost the entire margin I was ready to spend money on was prompt fit. To be fair to the paid model: it still won, and it won consistently. But at 8 points you switch everything. At 1.3 you switch selectively, if at all. Where the gap actually lives The per-category split was more useful than the total: 1. Fashion and apparel: 0. A dead tie across four picks. 2. Food and beverage: +3. 3. General product: +4. 4. Beauty and personal care: +14. One category carried nearly the whole result, and the reason was visible in the outputs. Beauty packaging is covered in intricate label illustration, fine serif type, botanical line work, small print sitting on a curved surface. That is a rendering problem with a right answer, and one model was measurably better at it.

If you have ever generated a set of product images and got ten slightly different products back, this one is for you. The symptom is always the same. A shade off on the third image. A seam that moved on the fifth. A button that disappeared on the eighth. The instinct is to go back and rewrite the prompt, add more adjectives, describe the product harder. It is almost never the prompt. The real cause is that nothing persists between generations. Every pass starts from zero and quietly re-invents whatever you did not spell out. Colour becomes a guess, material becomes a guess, the number of items in the box becomes a guess. You are asking a stateless model to remember something it never had. Three locks, in the order I would check them. 1. Confirm the references are actually arriving. This is the one that cost me the most time. A plain text-to-image endpoint will accept reference photos in the request and ignore them. No error, no warning - it just returns something confident and wrong. If your tool has an image-edit or image-to-image endpoint, references have to go through that one instead. Test it by sending a deliberately odd reference and seeing whether the output reacts at all. If it does not, the pictures are being dropped. 2. Lock the attributes once, as a profile. Colour, form, materials, finish - save them as a product profile rather than retyping them into each prompt. Retyped facts drift; saved facts do not. The profile then travels with every generation in the set, so the model is being corrected rather than consulted. 3. Extract the facts once, inject them everywhere. Pull one canonical fact set from the listing - product name, category, key attributes, whether text appears on the packaging, what is actually in the box - and inject that same set into every pass. This is what stops image three contradicting image one, and it is also what stops the model inventing a fourth item in a three-item box. The general principle is worth more than the images bit: anything you generate more than once needs state between the runs. Consistency is not a prompt trick, it is state you keep between generations.