grwm
Product Design · Development

The concept is built on my passion for style and fashion. Dressing generally comes down to three pillars:

• what's the weather
• where you're going
• who's going to be there

I wanted to give people a tool for getting the right outfit for the right occasion, and that's how the outfit-advice quiz idea appeared. The user selects {weather}, {occasion}, and {company}, and receives a styling recommendation.

For the first release, the goal was to prove the concept with one fixed look per combination.

Once the UI was done, I moved to the app's logic. My initial idea was to generate a separate item for each look, but that was too complex for an MVP, so I pivoted to 64 pre-made flat-lay looks, one for every {weather} × {occasion} × {company} combination.

From there, the challenge was assigning each look to its result string. With 3 questions and 4 answers each, the combinations resulted in 64 unique result strings, each needing storage in a table. This is where I started consulting with Claude, which helped me build the back-end pipeline: using Claude, I prompted Figma to create a SQL table and connect it to Supabase. The integration is built into Figma, so connecting it and running the SQL commands was straightforward.

Once the looks were uploaded to the Supabase table, I needed tooltips and descriptions for each one. To keep the process automated, I didn't want to hand-write descriptions for 64 looks, so I built this pipeline: the first time a look's image loads on the result page, a Claude API image-analysis function runs, generating a description and tooltips for each item in the flat lay. The same analysis maps the position of each item and generates coordinates for its tooltip (dot). The results are then sent to Supabase and stored in the table.

This pipeline works for two reasons:

• If I change a look later, I don't need to re-analyze the image or regenerate its description and tooltip coordinates.
• It runs only once per look, so I'm not paying for repeated API calls.

AI product manager Denys Bendovskiy helped build the image-generation pipeline, which ran across three models with three distinct prompts:

• Claude acted as the orchestrator across the pipeline, briefing Grok to write the batch script, and doing a final review pass to catch and fix sorting errors
• Grok wrote the bash script that ran the generation batch, then filtered out images that failed quality control and named the rest against the project glossary
• GPT-2.5 generated 300+ flat-lay images from the reference looks I provided

So: specs from Claude, generation from GPT-2.5, sorting from Grok, with Claude doing final QA. Three models, three prompts, two humans directing the pipeline.

Once the 64 final image files were ready, I uploaded them to Supabase. A dedicated function was set up to preload all image descriptions on upload, so users never wait on generation at result time.

The first testers (my friends) responded positively. They asked for more variety, since each combination currently returns one fixed look. That feedback points to the next iteration: generating a unique image per result rather than one fixed look per combination.