Inspiration

One of us has worked as a fashion designer. Inside a design team, length is not a mystery. A single inseam gets cut for a whole size range, and everyone in the fit session knows it will be wrong for a lot of the people who buy it.

So we talked to shoppers. Length came up constantly, and hardest from people whose proportions do not match whoever the sample was fit on. Height, leg to torso ratio, body type all move where a hem should land. The further you sit from the fit model, the more reliably the length is off.

Jeans concentrate it. Denim is rigid, so it does not drape its way out of a bad hem. The line either sits right on the shoe or it does not. And the shoe changes the answer, so the same pair is correct in boots and wrong in sneakers.

Mid-price retailers already pay for in-store hemming. They just have no way to deliver it to someone shopping online.

The product model on a PDP is 5'9". Everyone shorter is guessing.

What it does

Break is a plugin that adds one line to a retailer's product page: "Will these fit my length?"

It works from a pair you already own rather than asking for body measurements. Pick the brand, recognize the style by silhouette, select the size in that brand's own sizing scheme. Break reads that garment's published inseam and now has a benchmark that is a real object, not an estimate.

From there:

  • A verdict, in centimeters. "9 cm too long in your sneakers." Not a size suggestion.
  • Shoes as an input. Shoe height moves the correct hem by centimeters, so Break asks once and reuses it across the store.
  • Sequencing that respects irreversibility. The hem offer appears only after waist and hip are confirmed right for the size. Hemming cannot be undone, so it must never be offered before the reversible fit questions are answered.
  • A try-on of the outcome. As-shipped and hemmed, side by side, on the shopper's own body and in the shopper's own shoes.
  • A refusal path. When Break cannot back the number, it does not cut. The pair ships unhemmed with the hem prepaid, applied after the shopper confirms in person.

How we built it

Two YouCam APIs, chained rather than run in parallel:

  1. AI Shoes Virtual Try-On places the target footwear on the shopper's photo
  2. AI Clothes Virtual Try-On takes that output as input and places the garment on it

The chain is the point. Shoe choice is not a cosmetic toggle, it changes the hem the length engine is measuring to, so the shoe render feeds the verdict and the verdict determines what the clothes render shows. Both endpoints are async: submit a task, poll until the image is ready, which is why the UI has a real loading state rather than an instant swap.

The length math is our own layer sitting between the two calls. Benchmark inseam, garment inseam, shoe height offset, tolerance band on waist and hip.

Architecture is three layers. Screens exported from Claude Design and deployed to a live URL. A thin serverless proxy that holds the API key, since a key in browser-side code is a key anyone can read and drain. A render cache, because the demo catalog is a finite grid and paying for each render once beats paying every page load. The user photo upload path stays live and calls the API for real, which is the path a judge testing the app will hit.

One thing stated plainly: the two try-on renders in the demo are real YouCam API output. The catalog and lifestyle imagery is AI-generated placeholder for a fictional storefront, Rivet Denim Co., built so no real brand's photography or trademarks appear in the flow.

Challenges we ran into

The hardest problem was not technical, it was sequencing. An early version offered hemming immediately after the length verdict. That is a bug: hemming is irreversible, and if the waist turns out wrong the shopper is holding a garment that can no longer be returned. Fixing it meant gating the hem offer behind a waist and hip tolerance check, which reordered the whole flow.

The second was deciding what Break does when it is not sure. The easy answer is to always return a confident number. We built the opposite: an explicit state where Break declines to name a hem length and ships with the hem prepaid instead. A tool that makes irreversible cuts on weak signals is worse than no tool.

Accomplishments that we're proud of

The chain works as one decision, not two features. Shoe choice recalculates the verdict and both renders update together, so what the shopper sees is the consequence of what they told us, not a gallery of options.

The refusal path exists. It would have been easier to always return a number, and nobody would have noticed. Building a state where the tool declines to cut is the part we would defend hardest.

And the whole thing sits inside a real storefront flow, from product page to verdict to try-on to bag to order confirmation, rather than living as a demo screen off to the side.

What we learned

Chaining an analysis step into a rendering step is what separates a product from a wrapper. Most virtual try-on demos render. Rendering alone shows you what a garment looks like. Analysis driving rendering shows you whether to buy it.

Also: the strongest input a fit tool can ask for is not a body measurement. It is an object the shopper already trusts.

What's next for Break

A Shopify app as the wedge, targeting mid-price bottoms-led brands in the $80 to $300 range that already fund in-store alterations. The benchmark library is the asset that compounds: every brand and style whose published measurements we ingest makes the next shopper's verdict more accurate without asking them for anything new.

Built With

  • ai-clothes-virtual-try-on
  • ai-shoes-virtual-try-on
  • claude-design
  • css
  • e-commerce
  • figma
  • html
  • javascript
  • perfect-corp
  • react
  • rest-api
  • serverless
  • vercel
  • youcam-api
Share this project:

Updates

Submission history