Most explanations of app try on clothes technology describe how an image is made. For an app, that is the least useful half of the story, because most of what the app does was done weeks earlier.
Three separate things have to happen for a shopper to see a garment on a figure, and they happen at different times, on different machines, under different constraints. Two of them are finished before anybody opens the app. The third is what the shopper waits for, and it is usually the least interesting of the three.
Understanding which is which changes what you ask about a shopper-facing feature.
Three stages, one of them live
| Stage | When | Where | What it decides |
|---|---|---|---|
| Capture | Weeks earlier | Your studio or corner | Everything downstream. It is the only record of the garment |
| Asset production and checking | Ahead of launch | Your side of the line | Coverage, consistency across the range, and whether details are correct |
| Delivery | While the shopper waits | The app or browser | Speed, layout, and which existing asset appears. Not what exists |
Reading the fourth column, the pattern is that nothing decided at request time affects what a shopper can see. Coverage, accuracy and consistency were all settled earlier, by production decisions rather than by anything the app does.
That is why a fast, well-built app over an incomplete asset set feels worse than a plain one over a complete set.
Ahead of time: the production that decides coverage
The first stage is producing the assets, and it happens on your side of the line, on your schedule, from photographs of garments you control.
This is where every property the shopper eventually experiences gets set. Whether a style is covered at all depends on whether somebody produced assets for it. Whether the range reads as one set depends on whether the captures shared a standard. And whether a detail is correct depends on the check that happened here, since logos, printed text, care labels, and small hardware get compared against the source image on every single on-model output, without exception, and reconstructed detail lands almost right — a letterform slightly off, a stitch count wrong, a zipper pull the wrong shape.
None of that is recoverable later. An app cannot show a style nobody produced, cannot make an inconsistent set consistent, and cannot notice a wrong trim. Across a catalog at scale this is the stage that determines what the feature is, and it is entirely a production question rather than a software one.
At request time: mostly retrieval
The second stage is what happens when a shopper taps. In the common arrangement, the answer is: a lookup.
The assets exist. The app selects which ones apply to the style being viewed, in the colorway selected, at the size and format the device needs, and presents them. That is retrieval, formatting and layout — real engineering, and not image generation.
Two consequences follow. Latency and reliability are retrieval problems, which means they are solved with the ordinary tools for retrieval problems and are largely independent of anything about the imagery. And a shopper's experience of the feature working or not working is mostly an experience of whether an asset existed for what they were looking at.
That second point is worth dwelling on. When a shopper opens a try-on view and finds nothing useful, the usual cause is coverage rather than failure. The app did exactly what it was built to do and had nothing to show.
It also changes where an investigation should start. A team hearing that the feature is unreliable will usually look at the technology, since that is what the complaint sounds like it is about. The first question is narrower and answerable in minutes: which of the styles being complained about had assets, and which did not. A pattern normally appears immediately, and it points at the production schedule rather than at anything the app is doing.
The arrangement where something is produced live
A different arrangement exists, where something is produced at request time — most often in response to something the shopper supplies. It is a genuinely different engineering problem: it introduces latency that depends on the work rather than on the network, it puts a cost on each request rather than on each asset, and it means the output was not reviewed by anybody before a shopper saw it.
That last point is the one that matters most and gets discussed least. In the pre-produced arrangement, every asset a shopper sees passed a check. In the live arrangement, the check either happens automatically, or it does not happen. Whichever arrangement a product uses, that question is worth asking directly, because it determines whether the accuracy discipline described above reaches the shopper at all.
Both arrangements sit downstream of the same production work. Neither removes the need for garments to be photographed to a standard, and neither changes what the resulting image is. Where a single region of an asset is wrong and the rest is sound, a targeted correction to that region belongs to the production stage as well, which is another way of saying that fixes happen where the assets are made rather than where they are shown.
What no arrangement supplies
The output is a visual asset. It does not predict fit, determine sizing, model how a fabric behaves in motion, or forecast returns. Those come from measurements, a graded pattern, a physical sample, and your own data. Where the image was produced, and when, changes nothing about this, because the limit is in what the asset is rather than in the architecture around it.
So a size recommendation is a different system with different inputs — body data, garment measurements, and a returns history — and bundling it into the same interface does not make one produce the other. A size guide cannot be assembled from imagery at any point in the pipeline. And no arrangement should be justified against a return-rate or conversion outcome, since both sit at the end of a chain running through sizing, price, assortment, and traffic.
Color has a limit that no delivery surface closes. Screen color is not a physical reference, exact code matching is not something to promise, and the gap between a monitor and a roll of cloth stays open regardless of display quality. Colorways get settled by strike-offs against an agreed standard, and a device adds its own color handling on top of that gap.
Footwear is not covered by this class of workflow, and lace and open work, sheer fabrics, complex prints, and heavily layered looks are documented weak spots. Those verdicts belong to the production stage, so an app inherits them rather than affecting them.
What to ask, given the split
The split reorders the questions worth asking about a shopper-facing feature.
-
What proportion of the catalog has assets, since that is what a shopper experiences as the feature working
-
Who checked those assets against their sources, and whether that check was per output or sampled
-
Whether anything is produced at request time and, if so, what reviews it before a shopper sees it
-
Where the entry point sits on the page, since a feature nobody reaches has a coverage rate of zero in practice
-
What happens when a style has no asset, because the answer is a design decision and shoppers meet it
For teams on a hosted storefront, one route into this space is Lightchain AI Virtual Try-On for Shopify, from Lightchain AI (apparel AI), and the same split applies: the storefront side is delivery, and what it can deliver was decided by the production behind it. Deciding colorway direction and producing the assets is the part that sets the ceiling. Whether the work runs through Lightchain AI or a camera, an app shows what exists.
Frequently asked questions
Why does the feature seem to work on some products and not others?
Almost always coverage rather than failure: assets exist for some styles and not others, and the app has nothing to show for the rest. Ask what share of the catalog is covered before investigating anything about the technology.
Is the image generated when I tap?
In the common arrangement, no. What happens is a lookup of assets produced earlier, formatted for your device. Some products do produce something at request time, usually in response to an upload, and that is a different arrangement with different constraints.
Does a faster app mean better results?
It means better retrieval, which is worth having and is unrelated to whether the images are accurate. Speed is settled at the delivery stage and accuracy at the production stage, and the two do not trade against each other.
Can an app fix an inconsistent range?
No. Consistency is a property of how the garments were captured, and an app presents what exists. A range shot to three different standards will read as three standards however well the feature is built.
Who checks the images a shopper sees?
In a pre-produced arrangement, whoever ran the comparison against source before publication. In a live arrangement, the honest answer may be nobody, which is worth establishing rather than assuming. Ask the question directly.
What should happen when a style has no asset?
Something deliberate rather than an empty state, since shoppers meet it regularly at partial coverage. Falling back to standard product photography is usually better than an interface that appears broken, and it is a design decision worth making before launch.
In closing
Three stages, and only the last one happens while a shopper waits. Assets are produced ahead of time from photographs you control, and that stage decides coverage, consistency and accuracy. What the app does at request time is usually retrieval, which decides speed and nothing else. A variant exists where something is produced live, and its distinguishing question is who checks it. None of the three changes what the asset is, which is why fit, sizing, material behavior and physical color sit outside all of them.
Start here
Ask what share of your catalog currently has assets, and what a shopper sees on the styles that do not. Those two answers describe the feature as shoppers actually experience it, and neither is a question about technology. Most teams find the second one has never been decided, and it is the cheapest thing on this list to fix. Deciding it takes one conversation and changes what a shopper meets on every uncovered style.
**Start with the on-model workflow → **https://www.lightchainai.com/global/solutions/aiVirtualTryOn