Rewriting a live catalog without breaking it

The job merchants kept asking us to do by hand

On theme and Plus projects we kept meeting the same drag on page speed: a catalog of photos from three or four different sources, none of them sized for a shop page. The usual fix is somebody exporting a folder, running it through a desktop tool and uploading it again, which costs a day, loses alt text, and often breaks which picture belongs to which variant.

Before writing a line we read the one-star reviews on the tools already doing this. The complaints were consistent and specific: colors came back wrong, images were cropped badly, and there was no way to undo a run once the storefront looked broken. Those three became the spec, and they are the reason the app is built the way it is.

Six decisions that are not in any feature list

Each of these is a failure we designed out on purpose, and most of them only show up at catalog scale.

1. Color is the whole reputation

   The image library everyone uses defaults to discarding metadata, which throws away the color profile. Feed it a wide-gamut or print-space photo and the result comes back visibly wrong, which is precisely the complaint on competing tools. Every one of our pipelines ends by converting to standard sRGB and writing that profile back explicitly, so a photo that looked right in the studio still looks right on the product page.

2. Replacing a file breaks what points at it

   On Shopify an image is not a file you overwrite, it is a media record other things reference. The swap is therefore staged upload, create, poll until the new media reports ready, move it into the original position, and only then remove the old one. If it never reports ready we keep both rather than delete an original whose replacement is unconfirmed, and any variant attached to that image is re-pointed at the new media so no variant quietly loses its picture.

3. Metered billing has to be exactly right

   Charging per image means a retry can become a second charge. A scan that dies mid-page resumes from its last cursor and can legitimately re-read the same page, so the item table carries a uniqueness constraint and duplicate rows are dropped rather than created. Each slice sends one idempotency key, included credit is deducted before any early return rather than at the end, and images that were skipped or failed are never billed at all.

4. The bottleneck was the network, not the pixels

   Each image is a download, a transform, a staged upload and a wait for processing, so the process spends nearly all its time idle. Run one at a time it measured around 0.6 images a second, which is roughly nine hours for a twenty thousand image catalog. Slices now overlap several images at once while the transform itself is pinned to a single thread, and input is capped at 256 megapixels so one accidental decompression bomb cannot take down every other store's run with it.

5. A preview that cannot lie

   Nobody should approve a bulk change from a description. The preview runs real photos from the store through the identical pipeline the run will use, and the numbers shown are measured on the full size output while only the picture on screen is scaled down. The preview is also tied to the exact settings that produced it and is thrown away the moment a field changes, so a stale before and after can never be the thing a merchant approves.

6. Undo, or it is not really safe

   Every original is copied to persistent storage before it is replaced and kept for 30 days, restorable for a whole run or for one image. Restoring is itself a queued background job rather than a request that has to finish before the tab closes, and expired backups are swept and marked as expired in the interface, so the app never offers a restore it cannot actually perform.

Bulk work on a live store, done carefully

Most private app and migration briefs are a version of this one. Something has to be changed across an entire catalog, on a store that is taking orders while it happens, and it has to be reversible. That means resumable background jobs, a preview before commitment, references that stay intact after a record is replaced, and billing or throughput limits the client controls rather than discovers. Those are the parts we had to get right here, and they transfer directly.

What the app does, in short

• Resizes, compresses, converts and watermarks product and collection images in place, with nothing to download
• Five resize modes, three fit styles, and a quality and format choice on top of any of them
• Keeps color as standard sRGB and keeps variant images attached to their variants
• A free catalog health read, and bulk alt text from a template, neither of which is ever charged
• Scheduled and automatic runs, a spending limit the merchant sets, and 30 days of undo per run or per image

Full detail, every mode and the pricing are on the Miko Bulk Image Resizer product page, and the merchant guide is at miko.co.nz/docs/image-resizer/.

Two screens that carry the safety argument

When software is about to change thousands of things at once, the interface work is mostly about consent and reversal.