Calqen — AI Wardrobe Stylist

See new possibilities in the clothes you already own.

Comment

Inspiration

The closet can be full and the answer can still be missing.

Dinner is in an hour. The evening turned cooler than expected. You want to look put together, stay comfortable, and buy nothing. The right clothes may already be there; the hard part is seeing the right combination clearly.

I built Calqen around that moment.

Most wardrobe tools begin with inspiration or shopping. Calqen begins with a more practical question: what can I do with the clothes I already own?

Calqen was already a working wardrobe product before Build Week. It had authentication, wardrobe ingestion and tagging, profile and size memory, deterministic recommendation foundations, and a Vercel deployment. During Build Week, I used that foundation to create a production GPT-5.6 Decision Studio: a focused place to turn context into a clear wardrobe decision.

What it does

Decision Studio turns a real situation into exactly three complete, ranked looks from an authenticated owned wardrobe.

A user describes the occasion, weather, formality, comfort needs, and any constraints. GPT-5.6 interprets that context, builds three distinct options, and explains the reasoning and tradeoffs behind each one.

The user can then choose a look and refine it in ordinary language. In the judge journey, Calqen handles two requests:

  • “Make it warmer and use a different jacket.”
  • “Use different shoes and make it less formal.”

The requested pieces change while compatible parts of the outfit stay in place. Calqen reports both the changed and preserved roles, so a small request does not quietly become a completely different outfit.

The Source Board closes the loop. Every final component maps back to a piece in the frozen 19-item judge wardrobe. The demo creates exactly three looks, uses 15 of the 19 available pieces across those options, completes both refinements, and proves all five components of the final revised look as owned.

How I built it

The Build Week runtime uses gpt-5.6-sol through the OpenAI Responses API with a strict Structured Output contract.

The model proposes. The application verifies.

After authentication, the server loads only the eligible wardrobe pieces belonging to that user and turns them into short-lived, request-scoped references. Every model response is checked for ownership, completeness, role compatibility, diversity, constraint compliance, and targeted-change behavior before it can appear as a valid GPT-5.6 result. Unknown or hallucinated references are rejected.

A bounded repair path handles recoverable output problems. If a valid model result still cannot be produced, Calqen uses a clearly labeled deterministic fallback. It never presents fallback output as GPT-5.6 work.

The application is built with Next.js 14, TypeScript, React, Tailwind CSS, Turso/libSQL, Drizzle ORM, JWT and cookie authentication, Vercel Blob, and Vercel.

Codex worked beside me as the primary engineering collaborator during Build Week. It helped separate the pre-existing product from new work, isolate the implementation lane, investigate regressions, write tests and evaluations, review privacy and authorization boundaries, and assemble exact-release evidence. Product direction, scope, deployment, and publication decisions remained mine.

Challenges I ran into

The hardest part was not generating outfits. It was keeping the model useful without letting it become authoritative.

Wardrobe names and descriptions are user-controlled data. Provider output can be incomplete. A refinement that sounds small can accidentally replace most of a look. Those realities shaped the system: tenant-scoped candidate loading, request-only references, strict output validation, ownership checks, bounded repair, cost and timeout controls, and explicit fallback labeling.

The second challenge was evidence. Calqen existed before Build Week, so the entry needed a clear line between the original wardrobe foundation and the new GPT-5.6 Decision Studio. I treated that attribution work with the same care as the runtime itself.

Accomplishments I’m proud of

The result is a decision tool, not an open-ended styling chatbot.

  • It produces exactly three distinct, complete looks from an owned wardrobe.
  • It explains context, constraints, and tradeoffs in plain language.
  • It makes targeted changes while preserving compatible roles.
  • It proves final ownership through the Source Board.
  • It uses an isolated, unbranded judge account with repeatable 19-item seed and reset tooling.
  • Its deterministic evaluation suite covers 100 planning cases and 60 refinement cases.
  • Its bounded-live planning and refinement evaluations each passed 12 of 12 cases with exact gpt-5.6-sol, zero fallback, and zero hallucinated wardrobe references.
  • The verified desktop and mobile production judge journey completed with zero fallback, zero failed API requests, and zero browser-console errors.

What I learned

Grounding is not merely a backend safeguard. It is part of the experience.

A recommendation becomes more trustworthy when the user can see which owned pieces support it, what changed, what stayed in place, and why the final combination still fits the original situation.

I also learned that structured output is only the beginning. The application still has to protect identity and ownership, enforce constraints, validate targeted changes, manage quotas and timeouts, and decide what may safely reach the browser.

Codex was most useful as a persistent engineering partner across implementation, testing, review, and evidence. GPT-5.6 was most useful inside a narrow contract where the application remained responsible for truth.

What was added during Build Week

Build Week added:

  • The production GPT-5.6 Decision Studio runtime.
  • Structured three-look planning.
  • Targeted natural-language refinement.
  • Changed-versus-preserved role reporting.
  • Source Board ownership proof.
  • Request-scoped references and server-side response validation.
  • Quotas, timeouts, repair limits, and truthful fallback behavior.
  • Deterministic and bounded-live evaluation coverage.
  • The isolated judge wardrobe and guarded seed/reset workflow.
  • Desktop, mobile, Preview, and production release proof.

This entry does not claim that the entire Calqen application was created during Build Week.

Exact try-on is also intentionally excluded. A separate exact-preview and avatar research lane existed before this work, but Calqen does not currently claim photorealistic worn-on-body rendering, fit certainty, or a completed exact-try-on experience.

How judges can test it

  1. Open stylemingle.vercel.app.
  2. Sign in with the credentials supplied only in Devpost’s private testing field.
  3. Open Decision Studio.
  4. Use the scenario: “Outdoor dinner, cool evening, smart casual.”
  5. Keep the owned-wardrobe-only constraint and balanced comfort.
  6. Create and compare the three complete looks.
  7. Select a look and request: “Make it warmer and use a different jacket.”
  8. Then request: “Use different shoes and make it less formal.”
  9. Open the Source Board and verify every final component against the frozen judge wardrobe.

What’s next

The next step is to learn from real wardrobe decisions: better metadata, broader context memory, stronger accessibility feedback, and evaluation across more climates, body needs, and personal-style preferences.

Exact try-on remains deferred behind its own quality and privacy gates. Shopping and unowned-item recommendations also remain outside this Build Week entry.

Built With

Share this project:

Updates