The boring half of try-on

The flashy half of virtual try-on is the render: a fit appearing on your face. Demos live there. The product does not. The product lives or dies on a question nobody ever screenshots: is there anything real to try on.

Store inventory, seen from the inside, is chaos. The same garment photographed on a model, on a hanger, flat on a table. Names written for search engines, not for structure. Colors that exist only in marketing copy. Before any of it can go on a face, the system has to do something more basic than generation: find the garment in the image and know what it is.

That is a computer-vision problem before it is a generation problem, and it gets its own service: a Python endpoint running YOLOS to detect garments inside images and FashionCLIP to embed them, fashion-tuned vectors that let the system name a piece, compare it to its duplicates, and search it later. Generation collects the applause. Detection and embedding decide whether there is anything worth generating from. A try-on of a garment the system misunderstood is a very fast way to teach a user not to trust the mirror.

The catalog work runs as an offline pipeline, deliberately far from the request path. A person waiting on a render should never be waiting on catalog cleanup, so the split is absolute: users get milliseconds, pipelines get hours. Batch everything the user cannot see. Spend realtime only where someone is watching. Half of the architecture decisions in this company reduce to that one sentence.

Offline buys a second thing besides latency: the right to fail cheaply. A batch job that chokes on a weird product image reruns tonight and nobody notices; the same failure in the request path is a user staring at a spinner with their own face in it. Putting the flaky, messy, model-heavy work where failure costs a retry instead of a customer is not cowardice. It is putting the risk where the risk is affordable.

What comes out the other end is typed catalogue items, not cleaned-up scrape rows, and the rest of the app leans on that structure everywhere, down to the cart. Structure is not tidiness for its own sake; it is what makes every later feature cheap. The feed, search, the closet, checkout: all of them are one join away from the same clean spine, because the mess was paid down once, offline, where nobody was waiting.

Here is the opinion under all this. Everyone wants to build the model. Almost nobody wants to own the pipeline, and that asymmetry is exactly why the pipeline is the durable part. Rendering will get cheaper and better every quarter no matter what we do; every lab on earth is working on it for us. A clean, structured, try-on-ready catalog of real inventory improves only if someone grinds on it, which means it compounds precisely because it is boring. Glamorous work gets replicated. Boring work gets inherited.

Nobody will ever screenshot the pipeline. Every screenshot depends on it.