A shop that sells refurbished professional power tools has a problem that new-goods shops don't: there are no manufacturer photos. Every unit is different, so every unit has to be photographed, cleaned up and listed by hand. Per product that is a few minutes. Across hundreds of products it is days of work that you can't hand to anyone without the photo quality dropping.
I built a pipeline for Luko Tools, a Slovak shop selling refurbished Milwaukee, DeWalt and Makita tools. Today the owner's whole job per product is to upload the photos into a Google Drive folder, with the product name and price in the file name. This post is about how it is put together and, more usefully, where I deliberately stopped.
What the shop did before
For every product the same chain of steps:
- Photograph the product.
- Move the photos to the computer and sort them.
- Fix the quality (refurbished goods are shot in a workshop, not a studio).
- Remove the background so it looks like a product shot.
- Upload to WooCommerce and create the product.
- Fill in the name and attributes and assign a category.
How it works now
- Input: photos land in a Google Drive folder; the product name and price are taken from the file name. Nothing else is required from a person.
- Trigger: an n8n workflow watches the folder and starts by itself, no click.
- Upscale: the photos are enlarged and sharpened to sales quality by an image-processing service over an API.
- Background removal: a workshop shot becomes a clean product photo, again over an API.
- Product creation: the WooCommerce REST API creates the product with a gallery of the processed images and the name and price from the file name. A description, category and other details are filled in automatically, and the product goes live.
- Social post: once the product is live, an n8n step builds an Instagram and Facebook post from its photo and name.
The whole chain runs in n8n. The social post is the last step and only reacts to "a product is now live", so it stays independent of the part that fills the catalogue.
One constraint I'd repeat: don't touch the shop
The whole solution runs outside WooCommerce and talks to it, and to the social networks, only through official APIs. No plugin, no edits to the theme or the shop's code. That way it can't break the shop and the shop's updates can't break it in a way that is hard to trace. The price of this approach is a precondition: it only works if the platform has an API. WooCommerce has one. With another platform I would check that first.
What I left with a person
This is the part case studies usually skip, and it decides whether the thing is usable:
- Photography. The system processes a photo; it does not take one. A blurred or badly lit photo stays bad. Input quality sets output quality.
- Name and price. A person sets them in the name of the file uploaded to Google Drive. The description, category and other details are added by the system itself.
- Checking the result. A person only looks over the finished result. No errors so far, but that is an observation from one deployment, not a guarantee.
- Unusual items. Anything that doesn't fit the pattern is faster to create by hand, and that is fine. Not everything needs to go through the pipeline.
The trade-off I want to be upfront about
Unlike a workflow where a human approves the result, publishing here is automatic. The product goes live in the shop and the social post goes out without a further approval step. That was the right call for this shop and this kind of work — but it has a direct consequence: because nothing sits between the pipeline and the customer, the quality of the input photos is the only quality gate. If you build something similar for goods where a bad listing is costly, put an approval step before publishing.
Limits
- Image-service running costs depend on how many photos you process.
- It doesn't invent the name or price: it takes them from the file name, so they are only as correct as the name a person gives the file.
- It needs an API on the shop side.
Time and savings
Publishing one product from a photo takes about 30 seconds. I estimate the time saved at 3–5 hours a week, but it is an estimate, not a formal measurement. What changed in practice: instead of a chain of steps per product, one thing remains — upload the photos, with the name and price in the file name. The batch of hundreds of products runs unattended, and listing stopped being postponed, so products now reach the shop continuously instead of in occasional pushes.
The client's review is published on an independent portal (Jaspravim.sk), not written on my site. The full case page, with the diagram and limits, is here: nexflow.sk/en/case-ecommerce-products.
I'm Maksym, an independent automation developer in Banská Bystrica, Slovakia. I build Make.com and n8n workflows and AI agents, and I work in writing only: nexflow.sk.
Disclosure: this post was written by an AI assistant (Claude) from my project's published case notes. The facts come from my own project; the wording is the AI's.
Top comments (0)