Borrowed Confidence

• 

  Functional planner: 3/3 events, ₹0 purchase spending, one borrowed piece. Fictional sample inventory.

• 

  Fresh real YouCam outer result, Oct 30: synthetic inputs, 17.6 seconds, 2 units. Appearance only; not verified fit.

• 

  After real-result inspection and rejection: 3/3 coverage retained, spending ₹0→₹850, borrowed pieces 1→0. Fictional scenario.

• 

  Hosted app at 390 px: garment decision changes the actual wardrobe plan. Sample stock and prices; no reservations.

Dress for the opportunity. Not the shopping cart.

Inspiration

An interview on Tuesday, a career fair on Thursday, a final round on Friday. A student may already own the essentials but still need a suitable layer. Finding something attractive is only one part of the decision: can they obtain it for every date, return it on time, and stay within budget?

Campus clothing closets are an existing access model. Borrowed Confidence explores the planning layer around that model. We have not partnered with a university or validated student outcomes. Our inventory, prices and lending policies are explicitly fictional.

What it does

Borrowed Confidence plans several important events using clothes someone owns, can borrow, or could buy within a cap. It checks dates, availability, selected size group, dress requirements, unique borrowed pieces and a continuous loan window. A purchase is charged once even if reused across events.

The central journey is plan → select a garment from an actual outfit → inspect a YouCam appearance preview → accept or reject → recalculate. The selected garment and event travel into the studio. Accepting keeps the candidate in the shortlist; rejecting excludes that exact item across all events. The timetable then shows how coverage, purchase spending and borrowing changed. Nothing is automatically reserved or purchased.

Why YouCam is essential

The solver can tell us which garments satisfy the modeled constraints. It cannot show what a shortlisted layer might look like on a person. YouCam Clothes Virtual Try-On supplies that visual evidence; the human decides whether to keep the candidate. Their decision becomes a real planning constraint rather than a disconnected generated picture.

The server registers two consented images, uploads them to the returned signed PUT URLs, creates a cloth-v4 task with the selected category, and polls its status with bounded timeouts. A blazer uses outer; it is not silently substituted with upper_body. Keys remain server-side, and no render is triggered on page load or by automated tests.

The public experience offers a clearly labeled replay of a genuine October 25 authorized YouCam result. Its adult subject and blazer reference are synthetic demo assets. It does not use a visitor's uploaded photo or create a fresh render. Live rendering remains disabled until an operator securely configures credentials and verifies credits and spending limits. The functional adapter and its setup instructions are included.

How we built it

React and strict TypeScript, Express, SQLite, Sharp and Zod. A deterministic bounded search maximizes covered events, then minimizes unique purchase spending, borrowed pieces and total pieces. Stable ties make the result reproducible. It reports a partial plan when a complete one is impossible and rejects searches beyond its explicit node cap.

SQLite persists session ownership, job states and quota reservations; source images stay in memory. A single stable Node 24 process serves the application and asynchronous queue. Interrupted jobs become explicit errors after restart. The deployment uses persistent private storage and HTTPS rather than stateless serverless functions.

Design

The campus-editorial identity uses pine green, paper surfaces, garment schematics and a chartreuse opportunity ticket. The primary action opens the working planner. Each proposed outfit exposes its actual supported garments for inspection. A keyboard-operable before/after comparison, readable status states and a decision summary connect appearance to dates and spending. Illustrations, fictional stock, historical replay and live processing are labeled separately.

Technical evidence and evaluation

Two genuine YouCam smoke tests completed on October 25. upper_body took about 31 seconds and replaced the base shirt; outer took about 29 seconds and retained a visible white shirt beneath the navy blazer. Each cost 2 API units. These were not a controlled single-variable comparison because both source outfit and category changed. Both original results and their limitations remain preserved.

The seven-scenario evaluation retains the original fixture and records explicit input deltas. Independent exhaustive enumeration checks the objective and constraints. The baseline covers 3/3 events with ₹0 purchase spending and one borrowed piece. Stockout or rejection produces 3/3 at ₹850 with no borrowed pieces. A ₹500 stockout budget covers 2/3; making all layers unavailable covers 1/3. All seven have zero independently detected constraint violations. These are simulated scenario findings, not measured customer savings or human outcomes. See docs/EVALUATION.md for alternative counts and narrowly scoped local runtime measurements.

A third authorized real outer request on October 30 completed through the updated private UI in 17.62 seconds and consumed exactly 2 units, verified by authenticated before/after balances. The white shirt remained visible under the blazer. The revised 149-second narrated video uses genuine footage of that request, inspection, rejection, recalculation and the budget gap. Idle holds are cut; the full 17.62-second rendering interval remains uncut at actual speed. All original Deepgram narration plays at natural speed, and the actual decision report is enlarged for readability. Public access still uses the clearly labeled historical replay, with rendering disabled and no key on the public host. See docs/FINAL_LIVE_TEST.md.

The tested application is hosted at https://borrowed-confidence.52.202.25.181.sslip.io/ . A fresh anonymous Chromium context passed 19 hosted checks, including replay decisions, budget gaps, mobile layouts, origin/session behavior and exact revision. The current local automated suite has 42 passing tests, including consent, image validation, metadata stripping, origin/session isolation, persistent quotas, provider errors and interruption on restart. Chromium tests exercise the genuine replay decision loop and separately labeled HTTP-fixture progress/failure behavior. Fixture responses are never represented as newly generated live-provider evidence.

Challenges and limitations

The first provider result taught us that a top replacement is not the same operation as adding an outer layer. We preserved that failure of expectation and added the documented outerwear category. Another challenge was joining the preview to the actual optimizer: the original studio lost its garment context. It now carries the selected item and event, and rejection changes real planner input.

Generated appearance does not prove physical fit, sizing, fabric fidelity or successful purchase. The sample size groups are not measurements. The loan model uses calendar days, one continuous loan and same-day pickup; it omits lender opening hours, cleaning, deposits, shipping and taxes. Anonymous sessions are not verified user identities. Clearing a local session does not delete provider-held images. We have no actual student usability research, real stock integration or measured social/environmental outcomes.

What's next

A permissioned campus-closet pilot would test real availability policies and whether students understand the planning and preview decisions. We would evaluate garment quality across more consented inputs and improve lender scheduling before adding reservations. Those are future steps, not completed integrations.

Built With

• express.js
• react
• sharp
• sqlite
• typescript
• youcam-api
• zod