Photo by Kamran Abdullayev on Unsplash
Ask any agency what actually delays an ecommerce project and the answer is rarely the code. The theme is built, the payment gateway is tested, the staging site works. Then someone opens the folder the client sent and finds 340 photographs taken on three different phones, in four different rooms, half of them portrait, none of them cropped.
That folder is where launch dates go to die, and it happens on almost every build because nobody scoped it.
Cleaning Up What the Client Actually Sends
Client-supplied product photography arrives in one of three states, and each needs different handling.
Professionally shot images on white are the best case and the rarest. Reasonable photographs with cluttered backgrounds are the common case: usable, but shot on a desk, a shelf, or a shop floor with other stock visible. And phone snapshots taken in poor light are the case nobody plans for.
The middle group is where most of the work sits, and it is also where the fix is most mechanical. Running those files through a background remover first gives you a consistent starting point, and tools such as Pixelcut, an AI photo editing app that also handles upscaling, batch resizing, and AI product photography, will process a catalog in bulk rather than one file at a time. That distinction matters at 340 items, where a per-image workflow is several days of somebody’s time.
The third group needs a conversation with the client rather than a technical solution. No pipeline saves a photograph taken in the dark.
Decide the Image Spec Before the Design
The single most useful thing an agency can do is fix the image specification before design begins, not after.
That means agreeing on a small set of decisions and writing them down: background treatment, aspect ratio, minimum resolution, whether products get a contact shadow, and how much margin sits around the subject. Five lines in a document.
Skip it and every product page becomes a negotiation. Worse, the theme gets built around whatever the first ten sample images looked like, and the remaining 330 do not match.
Transparency Is More Expensive Than It Looks
Here is the technical point that catches developers who have not dealt with high image volumes.
Removing a background produces transparency, and transparency has historically meant PNG. PNG uses lossless compression, which is excellent for logos and flat graphics and poor for photographs, where every pixel differs slightly from its neighbor and there is almost nothing to compress. Add the alpha channel and you have a fourth channel of data per pixel before compression even starts.
The result is product images several times larger than they need to be, sitting on a category page forty at a time.
WebP solves this properly because it supports both an alpha channel and lossy compression, which PNG never could. Convert on the way into the media library rather than serving PNG and hoping the CDN sorts it out.
Placeholder Images Are a Trap
Every build uses placeholders during development, and every agency has shipped one by accident at least once.
The risk is not the obvious grey box, which somebody always spots. It is the plausible placeholder: a stock photo of a similar product, dropped in so the layout can be reviewed, that survives into production because it looks like a real image.
Two habits prevent it. Use placeholders that are visibly wrong, ideally with the word placeholder rendered into the file, so nobody mistakes them for content. And keep a list of which products still lack final images, checked as a launch gate rather than remembered.
The second one matters more than it sounds. On a 340-product catalog, nobody can tell by looking whether every item has its real photograph.
Naming Decides Whether Any of This Can Be Automated
Filenames feel like housekeeping until you try to script something.
A convention that encodes SKU, variant and asset type lets you match images to products programmatically during import. Filenames like IMG_4471_final(2).jpg mean somebody matches them by hand, and at catalog scale that is where the real cost is.
Two rules cover most of it. No spaces or special characters, because they break in URLs and in scripts. And put the identifying information in the filename itself, so a file separated from its folder still says what it is.
Agree this with the client at kickoff. Renaming 340 files after the fact is nobody’s favorite afternoon.
Who Owns the Images After Launch
This is the handover question that generates support tickets six months later.
The client will need to add products. If the image workflow lives in your agency’s process, in your tooling, and in the head of one designer, every new product becomes a change request. If it lives in a one-page document the client’s own staff can follow, it does not.
Write the spec as something a non-designer can execute. Which tool, which settings, which dimensions, where files go. That document is worth more to the client than any amount of polish on the launch-day catalog.
Marketplace Requirements Are Not Optional
If the client also sells through marketplaces, and most do, those platforms impose their own image rules independently of anything you build.
Plain backgrounds on the main image, minimum dimensions, the product occupying a defined share of the frame, no promotional text overlaid. A listing that fails these does not go live, and the client will assume the website build is at fault.
Ask early whether marketplace listings are in scope. If they are, the image spec has to satisfy the strictest platform in the mix rather than just the site you are building.
Alt Text Is Not Only an Accessibility Task
Most developers know alt text is required and treat it as a compliance checkbox to be filled in at the end, usually badly.
It is worth reading what the government program that enforces it actually says. Section508.gov’s guidance on authoring meaningful alternative text defines alt text as descriptive text conveying the meaning of an image in digital content, designed to make visual content accessible to people with vision disabilities, and notes that without it, screen reader users cannot access the content the image provides. That is the part everyone knows.
The part worth quoting to a client is what follows. The same guidance points out that alt text also makes content accessible to users who have difficulty understanding visual content and to users without high-speed internet who cannot load images, and that it makes visual content available for technical applications including search engine optimization, digital assistance, and artificial intelligence.
For an ecommerce build, that reframes the task entirely. Alt text on a product image is simultaneously an accessibility requirement, a source of product data for search engines, and increasingly the way AI systems understand what the image contains. Generating it from the product title and attributes at import time costs nothing and does all three jobs at once.
Put the Pipeline in the Scope Document
Almost every image problem on an ecommerce project is a scoping failure rather than a technical one.
Decide who supplies images and in what state. Fix the specification before design. Agree naming at kickoff. Decide who processes what, and hand the client something they can follow afterward. Budget the hours honestly rather than absorbing them.
None of that is difficult. It is simply the part of the build that nobody quotes for, which is exactly why it is the part that slips.
Leave a Reply