TryOnReady

Virtual try-on that a small boutique can actually run.

Comment

Inspiration

Independent boutiques compete for the same shoppers as national retail platforms, but usually without dedicated engineering, security, catalog, or integration teams. TryOnReady started with a practical question: how can a small shop offer apparel virtual try-on without turning the owner into an API operator or exposing customer images?

Our synthetic boutique, Luna & Thread, represents that resource gap. Elena Rivera prepares one garment once, an administrator verifies it, and a guest shopper such as Marisol Lopez can use the approved experience without opening an account.

What it does

TryOnReady adds an operating and trust layer around YouCam AI Clothes v3 / Apparel Virtual Try-On:

  • A boutique submits a guided application and confirms its rights to garment imagery.
  • The retailer adds a garment and passes image-readiness checks.
  • An administrator approves the boutique and garment before customer use.
  • A guest shopper selects an approved garment, reads the privacy and visualization limits, gives consent, and provides an authorized image without creating an account.
  • The server controls provider credentials, asynchronous processing, duplicate prevention, API-unit accounting, private result delivery, and cleanup.
  • The retailer sees aggregate operational results—not shopper source or generated images.

The deployed judge experience uses only clearly labeled synthetic adults and merchandise. It includes a previously completed controlled demonstration of YouCam AI Clothes v3. Playback makes zero new provider requests and does not claim a new unit was consumed. Virtual try-on visualizes appearance; it does not guarantee physical fit or sizing.

How we built it

The responsive interface is built with Next.js, React, and TypeScript. A single ASP.NET Core 10 host serves the exported web application and API from one origin.

The application layer uses explicit ports for catalog, approval, private storage, and virtual try-on. EF Core 10 and PostgreSQL persist boutique applications, approved products, job state, duplicate fingerprints, provider references, and aggregate usage data. Images remain outside the public web root.

The YouCam adapter implements the full AI Clothes v3 server workflow: reserve file identifiers, upload the person and garment images to signed HTTPS targets, create a task, poll its status, securely retrieve the result, and clean up provider resources. The browser never receives a provider credential.

The judge deployment runs on isolated Fly.io app and PostgreSQL Machines in San Jose, with encrypted persistent volumes, health checks, automatic restarts, release migrations, daily snapshots, a tested restore rehearsal, and a stored-result fallback.

Challenges we ran into

Turning an API call into a safe retail workflow

The provider task is asynchronous, but a boutique needs clear states and predictable recovery. We modeled submission, processing, polling, success, failure, and cleanup explicitly. Request fingerprints return the existing result for an unchanged product/person pair instead of creating a duplicate provider task.

Keeping private images and credentials out of the wrong places

We kept the YouCam key entirely server-side, stored images outside the public web root, separated retailer/admin authorization, prevented retailer access to shopper imagery, constrained upload size and concurrency, and documented deletion boundaries.

Creating a stable judge experience without misleading anyone

A live provider dependency can fail or consume units whenever a judge repeats a demonstration. We preserved a verified synthetic result from a controlled successful run and display it with exact provenance: previously completed controlled demonstration; playback makes zero new provider requests. The live adapter remains implemented independently from the replay mode.

Deploying a complete product within a small operational footprint

We separated the application and PostgreSQL resources while keeping both in one region. Release migrations, non-root execution, restrictive production headers, private database networking, persistent volumes, snapshots, rollback, and restore instructions had to fit a lean shared-Machine deployment.

Accomplishments that we're proud of

  • A coherent retailer-to-shopper workflow rather than a thin API wrapper.
  • A complete server-side YouCam AI Clothes v3 adapter with no browser credential exposure.
  • Human approval and garment readiness before a shopper can begin.
  • Guest consent, private results, duplicate prevention, and aggregate retailer reporting.
  • A judge-accessible deployment with a synthetic, provenance-verified controlled result.
  • Clear product limits: no real-customer claim, no fit guarantee, and no unsupported conversion or return-reduction claim.
  • Automated .NET, TypeScript, and browser test foundations plus production security and recovery controls.

What we learned

The largest lesson was that the AI generation call is only one part of a usable retail product. The difficult—and valuable—work is everything around it: input readiness, human approval, consent, asynchronous state, duplicate control, unit accounting, privacy, cleanup, and a recovery path.

We learned that asynchronous provider APIs need explicit application states and idempotency. Treating a retry as a brand-new request would waste units and confuse shoppers; fingerprinting the unchanged request lets us reuse a valid result.

We also learned that privacy claims have to be enforced architecturally. Keeping credentials on the server, storing images outside the public site, separating roles, and limiting retailer visibility are stronger than relying on interface copy alone.

Finally, we learned that a credible demonstration needs provenance and precise language. A stored result is useful evidence only when we identify when and how it was produced, label synthetic people and merchandise, disclose that playback makes no new provider request, and avoid claiming fit, sizing, conversion, or return outcomes that have not been measured.

What's next for TryOnReady

The next step is a measured boutique pilot with human approval. We would evaluate reliability, staff effort, shopper completion, controlled API cost, duplicate prevention, deletion compliance, and privacy—not assume conversion lift or return reduction in advance.

We also plan to refine catalog onboarding, improve accessibility and operational monitoring, and validate whether the workflow remains simple for a real small-business team while preserving the same server-side credential and private-image boundaries.

Built With

Share this project:

Updates