Catalog image studio

Enriching product images meant opening a design tool, editing each size of each product by hand, exporting, and uploading them one by one to the store back office. For a catalog with many variants per product, the work did not scale, and nothing recorded which images had already been processed.

The editor runs in the browser and works on layers, saved as templates so a look can be reapplied across a product line. Rendering happens on the server with an image processing pipeline, never in the browser, so output is identical regardless of who exported it. The layer definition arriving from the client is validated against a schema before it reaches the renderer, and asset downloads are restricted to an allowed set of hosts.

Publishing is the part that had to be careful. The render is uploaded to object storage first, because the store platform ingests images by pulling them from a URL. Every file name carries a date and a content hash, since reusing a name leaves the old image cached in the delivery network for days. The pipeline then removes only the previous renders it recognises as its own, never the primary or hover image, and archives the original it replaced so the change is reversible.

Rendering on the server instead of exporting from the canvas was the decision that made batch publishing possible. One code path produces every image, so a product with many variants is a loop rather than an afternoon.

The file naming rule exists because of how content delivery networks cache. A unique name per render is the only reliable way to guarantee shoppers see the new image, and it doubles as a marker that identifies which files this tool produced.

Never touching the primary image was a hard constraint from the start. The tool adds to a product's image set and cleans up after itself, which keeps a bad render from ever becoming the face of a product listing.