Fit Check

A refusal-first shopping advisor: reads your skin, then says which products are worth buying — and which to walk away from, with the reason why.

Comment

Inspiration

Everything YouCam sells is generative: it renders what you ask for. The gap is that nobody upstream of the render is qualified to ask. People try on the wrong things, and eCommerce returns are driven by "it looked different on me." So we built the part the API does not do — the decision that comes before the render.

What it does

Fit Check is a refusal-and-budget advisor for virtual try-on.

  • It runs a YouCam Skin Analysis on a photo (or on a built-in demo profile), reading up to 16 concerns.
  • It evaluates a catalogue of candidate items against that skin profile using a rule-based advisor that reasons about tone, finish and pattern.
  • It refuses items the analysis argues against — with a stated reason, not a disclaimer. "This is a warm, saturated tone and your redness reading is 68/100 — warm tones amplify facial redness."
  • It keeps the items no rule fired against, and shows the rejected candidates alongside the chosen ones, each with the reason it lost.
  • It spends deliberately: a visible unit budget, per-render cost read from the machine-readable cost API, and a stated trade-off between the skin read and the renders it buys.

A judge sees a decision, not a picture.

How we built it

The repo has three layers, deliberately separated:

  • youcam_client.py — a thin, honest client over the YouCam S2S API. Auth, upload, task submit, poll, fetch result. Nothing clever on purpose.
  • decision.py — reads the skin profile, asks the advisor about every candidate, spends a visible budget, and produces a plan: what was kept, what was refused, and why.
  • advisor.py — the pluggable interface. The published repo ships one honest reference implementation (rule-based, deterministic, offline). An optional private drop-in can implement the same interface with a different brain; it is deliberately not included and never committed.
  • cost_model.py — per-feature unit costs and a budget ledger that tracks every spend with a reason.

Python throughout. The Streamlit UI shows the same thing as a product rather than a demo: two columns — chosen and refused — each with its reason, a budget meter, and an expandable decision trail.

Challenges we ran into

The API client was built and tested against mocks, and it looked fine. The first live call with a real key failed: the client was pointed at the marketing site host rather than the S2S API host, so every request returned a 403 HTML page. Fixing the host exposed a second, deeper defect that mocks could never have caught — the file API answers {"status": 200, "data": {...}} while the client parsed {"result": {...}}, requests comes back as a list rather than an object, and file_size is required on upload.

That was three defects, not one, and they were only findable with a real key and a real upload. It changed how we think about mocked tests: they prove the code is self-consistent, not that it is correct.

Accomplishments we're proud of

  • A refusal is the one output an image generator cannot produce. It cannot be confused with the vendor's own getting-started page, because the vendor's API does not do it.
  • Every decision has receipts. 22 units for the skin read, 2 per render, and a ledger that states exactly what was spent, why, and what was left.
  • It runs with no key and no network. The published reference advisor is deterministic and offline, so a judge can clone the repo and see the whole product on the first run.
  • 70 tests pass, covering the cost model, every tone/finish/pattern combination, the full decision pipeline, and the client's error handling.

What we learned

That "just call the API" is the easy half. The hard and valuable half is deciding what is worth calling it for. We also learned that a live credential is a test surface no mock can replace — our three real bugs were all invisible until a real key touched a real endpoint.

What's next

  • Swap the reference advisor for an LLM-backed drop-in behind the same interface, so the reasoning generalises beyond the rule table.
  • Feed the cost API into the planner so the budget adapts to the user's actual unit balance.
  • Extend the catalogue reasoning to the Apparel VTO render path end to end.

Built with

python, requests, streamlit, pytest, YouCam Skin Analysis API, YouCam Apparel VTO API

Built With

Share this project:

Updates

Submission history