-
-
The page a judge lands on: honesty banner in the first viewport, access-code link in the header, real photo beside its YouCam render.
-
The hero comparator: one photo, and the YouCam Apparel VTO render of it. Same person, same wall, same light - not a stock before/after pair.
-
YouCam Skin Analysis: ten 0-100 scores, lowest first, framed as priority areas. These drive the countdown.
-
YouCam Skin-Tone Analysis: undertone, depth and palette, from the colours the API detected on this photo (skin #b7947d, hair Auburn).
-
One cross-category priced basket: skincare, the garment and matched accessories. The retail case on screen rather than asserted.
-
The Apparel Try-On render, captioned with the API that made it. A real cloth-v3 render of this photo, with a receipt committed in the repo.
-
The selfie-only path: a captured YouCam skin mask of the SAME face beside it. An unknown photo gets an honest refusal, not a stranger.
-
The judge gate. The code in the Testing instructions unlocks live YouCam runs, and the remaining run budget is stated before you spend it.
-
The provenance ledger: four Perfect Corp APIs named, and it still says plainly that nothing was called during this run.
-
The look board: the hero is the try-on render the plan promises, and the countdown changes in KIND with the date.
-
Why this garment: the factors in weight order. It says out loud that the YouCam undertone was OUTWEIGHED by occasion fit on this run.
Try it first — hosted, keyless, zero API units: https://aphrodite.max-gutowski.de
4 YouCam APIs in the chain, 3 with a visible render on the sample path — Skin Analysis → Skin-Tone → Apparel Try-On → Photo Lighting. The relight is absent, not borrowed: no capture of that face exists, and the on-screen ledger says three.
~4.5 s for the whole loop, measured on the hosted instance.
0 API units to look — every public path is fixture-served, and the page says so on screen.
112 tests in 12 files; tsc / lint / build green too, measured 2026-08-12.
8 APIs declared, 3 rendering on a reachable path — the honest surface, see "YouCam APIs used".
88 s demo video with spoken narration, inside the 1–3 minute window, cut from a production build.
Live renders and the LLM engine are behind an access code, because both spend money. The judging code is in the Additional info section of this submission, which Devpost shows to judges and organizers only; redeem it at https://aphrodite.max-gutowski.de/unlock . A live run takes about three minutes because it makes four sequential YouCam calls and polls each to completion, so a run that looks stalled is still polling; the keyless path takes about 4.5 seconds.
Inspiration
Most virtual try-on demos stop at "here's a garment on you." Before a wedding or an interview I actually want three things answered in one place: what do I do with my skin between now and the day, what should I wear for my coloring, and where do I buy all of it. Aphrodite answers all three from a single photo — fusing YouCam's Skin AI and Apparel VTO into one occasion concierge rather than two separate toys.
What it does
- Reads you with YouCam AI. Skin Analysis (0–100 health scores — it focuses the lowest ones), Facial Color / Skin-Tone (it derives your undertone and a palette from the detected colors), Apparel Try-On (the outfit rendered onto your photo), and AI Photo Lighting (a camera-ready finish).
- Plans the occasion. A skincare countdown that changes in kind with how far off the event is — weeks out it front-loads active ingredients and tapers; a day out it stops new actives and switches to hydration and de-puffing so nothing flares on the day.
- Dresses you for your coloring. Your detected undertone drives the outfit pick (a cool read leans to cool-flattering pieces), with explicit guards + tests so the styling is never mis-gendered — and the garment is rendered on you, not just described.
- Completes the look. One cross-category, priced basket — skincare + garment + matched accessories — with an on-screen provenance ledger naming which YouCam API produced each result.
- Keeps going. Save an image-free plan (no photo, mask, or raw API response stored) and return for a glow check-in that diffs your scores against the saved run. A studio for hair color, hairstyle and makeup is wired but not shipped — see "YouCam APIs used".
How I built it
- Next.js 16 / React 19 / TypeScript / Tailwind v4, streamed over Server-Sent Events. The whole concierge is one streamed route plus one client component.
- Two engines, one event stream. An agentic engine (Claude or GPT) orchestrates the YouCam REST APIs via typed function-calling tools, reasoning over your scores; and a guided rule engine produces the same board with no LLM at all. They emit an identical event stream, so the UI doesn't care which drove the run. The app works on a YouCam key alone; the LLM is a pure upgrade.
- YouCam / Perfect Corp AI API drives every render over REST: Skin Analysis, Skin-Tone / Facial Color, Apparel Try-On and AI Photo Lighting. Three further endpoints are wired but render nothing, and are not counted — see "YouCam APIs used".
- Cost-safe demo mode. A fixture/replay layer serves real captured YouCam outputs so the entire app — plan, try-on, refine, save, check-in — runs with zero API units and no keys, and the UI labels itself "demo mode · sample renders" so nothing over-claims.
- Hardened boundary. zod request validation, per-IP rate limiting, a payload-size cap, and raw provider fields stripped out of the stream. 117 Vitest tests in 12 files (occasion parsing, garment selection incl. mis-gender guards, the cut preference, the access gate, the provenance ledger, request validation, raw-field stripping, rate limiting, and the evidence route);
tsc/lint/buildgreen — all four measured 2026-08-12.
YouCam APIs used
Four render on the sample path a judge drives: Skin Analysis · Skin-Tone / Facial Color Analysis · Apparel (Cloth) Try-On · AI Photo Lighting.
Every render you see in demo mode is a real capture of the photo it is shown on, and
each one has a committed receipt under hackathon/receipts/ with the provider's own task
id, poll envelopes and a sha256 of the bytes YouCam returned. Renders are keyed to the
person they depict: hand the app a photo it has no capture for and it says so rather than
showing you someone else. Two faces, two garments — the wedding sample is rendered in
the Slate Blue Three-Piece Suit, the second sample in the Sky Wrap Maxi Dress her own
colour read selects, both real cloth-v3 renders of their own photos.
Wired but not shipped, so not claimed: AI Hair Color (slug verified, no captured fixture), AI Makeup and AI Hairstyle (slugs never verified — the key 401s on those features). The studio tiles that would call them return an honest empty state instead of an image, and this submission does not count them. Declared endpoints: 8. With a calling module: 7. Slug-verified: 5. Rendering, with a committed receipt each: 4.
The special-category goal — Skin AI and Apparel VTO fused into one experience — is the core loop: the same skin read that drives the skincare countdown also feeds the coloring that drives the outfit that gets rendered on you.
Challenges
- Coherence across horizons. Making the countdown differ in kind (weeks vs. a day out) instead of just restating scores took real rule design, and keeping every "→ product" chip resolvable to a priced basket row.
- Not mis-gendering the styling. Undertone-driven selection kept defaulting to one wardrobe; fixing it meant reworking the scoring and expanding the catalog, locked down with regression tests.
- Honesty under demo constraints. A render is a claim about whose face is in it, and that turned out to be the hardest constraint in the build. Captured fixtures were keyed by kind of garment, so an uploaded photo got a stranger's render under "Your outfit", and the board's hero image was a fourth person captioned "rendered by YouCam AI". Both were found by looking at the frames, not by reading the code. Fixtures are now keyed to the person by content fingerprint and to the garment by id; everything else refuses and says so. The visible cost is that the sample path credits three APIs instead of four — which is the point.
Accomplishments I'm proud of
A complete, coherent product — not a PoC — that a beauty/fashion retailer could drop into its own funnel, with a genuinely honest demo and a swappable catalog + theme. And the two-engine design: the same experience with or without an LLM.
What I learned
How much of a "wow" try-on demo is actually product coherence — timing, provenance, honesty — rather than any single render. And that adversarial self-review (scoring against the real criteria each cycle) catches over-claims faster than building more features.
What's next
- Capture the studio try-on fixtures + a cool-tone full-body render so the fully-fused chain renders on screen in the zero-cost demo.
- Point the catalog at a real retailer's live products so the shoppable basket becomes a live storefront.
- Widen the menswear catalogue past its single garment.
- Widen the captured set so any uploaded photo can be answered with its own render rather than an honest refusal — today that needs live units, which is exactly what the access code unlocks.
Built With
- anthropic-claude
- next.js
- openai
- perfectcorp-youcam-api
- react
- server-sent-events
- tailwindcss
- typescript
- vitest
- zod

Log in or sign up for Devpost to join the conversation.