Building Calqen: From a wardrobe problem to a working demo
Calqen began with an ordinary decision that can become surprisingly noisy: what should I wear from the clothes I already own?
Here is what it does. You give Calqen an occasion, the conditions (such as the weather), a style direction and a wardrobe you supply. It returns three complete outfits to compare, each with a short reason. You can then ask for one change, say a warmer jacket, and it changes that piece while keeping the rest where it can, showing which of your clothes each look uses. It was never meant to invent a fantasy closet or simulate an exact try-on. What exists publicly is a recorded demo video and a preview link: a demonstration, not a released product with users.
The problem
Most wardrobe tools begin with more: more products, more recommendations, more things to buy. Calqen begins with a smaller question: given this occasion, these conditions, this style direction, and these available clothes, what are three coherent ways forward?
The intended user is someone who wants a useful decision from a wardrobe they supplied, not a claim that the system has independently verified their closet, body, fit, or personal taste.
The Build Week constraint
Calqen was built for OpenAI Build Week 2026. The public demo shows a GPT-5.6-assisted path inside a deliberately bounded product flow.
The build still had to do more than return text. Every result needed the same predictable shape: three complete looks, the occasion and direction they answer, a way to refine one look, and the clothes each look uses. When the live model couldn’t return a usable result, the app had to show a clearly labeled fallback instead of passing it off as a live answer.
What was built
The Decision Studio is the main screen. It collects the occasion, conditions, style direction and the wardrobe you supply, and produces exactly three complete looks, each with a short rationale and a confidence signal. That signal is the app’s own label, not a measured accuracy. A selected look can then be refined around a specific request.
The Source Board is a panel listing the wardrobe pieces behind the final look, so the recommendation can be checked against the supplied clothes rather than accepted as a polished paragraph.
What AI accelerated
AI helped compare the supplied pieces, translate constraints into structured options, generate rationales, and respond to a specific refinement request. It made exploration faster and helped turn a large combination space into three readable decisions.
What the tools could not settle
The model could not decide what “better” meant for this person in this moment.
Should a warmer result favor familiarity or novelty? Should formality increase or decrease? How much explanation helps before it becomes noise? When a jacket changes, which other parts must remain untouched? Those are product judgments, not merely generation tasks.
The human product decisions
Use only the supplied wardrobe.
Return three complete options rather than an open-ended list.
Treat a refinement as a bounded promise: change the requested role and preserve unrelated roles where possible.
Explain what changed and what stayed.
Keep the source pieces visible.
Label fallback behavior honestly.
Keep exact try-on, body rendering, and fit certainty outside the claim.
Keep three claims separate: that a feature works, that it’s deployed, and that the public video actually shows it.
What changed during the build
The early temptation was to reward variation. A request for a different jacket could easily become a different outfit. That looked active, but it did not necessarily look like listening.
The refinement flow was revised around changed and preserved roles. Testing was also tightened, so a result that merely looked right didn’t count as working. Each part got its own check: that the result had the expected shape, that its pieces came from the supplied wardrobe, the provider state (what the AI service actually returned: a usable live result, or a failure or unavailable response that sent the app to its labeled fallback), that it was labeled correctly, and that the public video showed it.
Current public state
The Calqen demo is publicly viewable on YouTube. The captured video shows the Decision Studio, three complete looks that passed those checks, targeted refinement, and the Source Board. The video also carries YouTube’s AI-content indicator. Captions are present; caption accuracy remains a separate review item.
Public demo video:
Current product preview used by the channel: https://stylemingle.vercel.app...
The product-preview link was rechecked immediately before publication. The public state described here does not imply adoption, customer demand, revenue, or production readiness beyond what the linked surfaces visibly show.
Known limits
Calqen is not exact try-on or virtual try-on.
It does not render a person’s body or guarantee fit.
It does not independently verify wardrobe ownership.
The prepared demo uses a bounded wardrobe and scenario.
A recommendation is not a statement of personal certainty.
No adoption, demand, outcome, accuracy, revenue, or product-market-fit claim is made.
Reusing owned clothes may support a lower-purchase decision, but no sustainability impact was measured.
What I learned
The useful part of an AI product is often the boundary around the generation.
What may change? What must remain? What evidence lets a person inspect the result? What happens when the model is unavailable? Who is responsible for the final claim?
Those questions shaped Calqen more than the number of possible outfits.
The next product decision
The next decision is not how to generate more. It is how to make the comparison, refinement, and evidence easier to understand without pretending the recommendation is more certain than it is.
Sources and evidence
Public Calqen demo video:
Current public product-preview destination: https://stylemingle.vercel.app...
Build Week testing and scope records were reviewed locally for the claim boundaries above; private job identifiers, credentials, and account screenshots are intentionally not published.
