Outfittr

I'd see an outfit online that I liked and have no idea where any of it came from. Nobody tags the pieces. You either ask in the comments and hope, or give up.

I wanted to take a screenshot, isolate each garment, and find it — or something close enough.

The core flow is still that: upload a screenshot or photo, Outfittr detects the visible garments, you pick one, and it surfaces exact and similar matches with store links and prices. Around it grew a set of things people actually wanted to do with a fit once they had it.

• Virtual try-on: your photo plus a garment image, with stylist notes on making it work.
• Rate: an outfit score with a verdict, strengths and fixes. Roast mode for people who asked for it.
• Fit battle: two looks side by side, one winner, a full breakdown.
• Share: 9:16 story cards and short links that open the full result on the web, no install required.
• Pro subscription with weekly style credits.

I used AI throughout development and owned the architecture, implementation, product decisions, and release.

• Gemini identifies the garments and provides search descriptions; SerpAPI retrieves marketplace results. Keeping those responsibilities separate lets the search strategy change without replacing garment detection.
• Supabase manages credits on the server so the app’s interface cannot decide whether a paid action is allowed.
• RevenueCat over hand-rolled StoreKit for subscriptions, so I could spend the time on the product instead of receipt validation.
• Share links open on the website. Someone who sees a card in a story should be able to see the result without being asked to install anything first.

The feature I'm proudest of isn't the hardest one. The share cards turn an outfit and its result into a single object someone wants to post: the photo, the score, the verdict, in a 9:16 frame that looks right in a story.

I cared about how they looked and felt, not just whether they technically exported. That was new for me, and it's the part of the app that made people want to show it to someone else.

I assumed that because the flow made sense to me, it would make sense to someone else.

I had a friend test the version that was already on the App Store. While he used it I kept explaining what to press next, where to go, what that button meant. At some point I noticed that if I had to narrate the app, the experience wasn't as intuitive as I thought.

Working alone for a year, I'd stopped noticing where a new person would get confused. I went back and rethought parts of the UX instead of assuming the implementation was fine because it worked. Now I try to watch someone use what I build before I explain anything.

The search pipeline starts with Google Lens through SerpAPI. It then checks whether the results include usable product links, prices, and images before deciding how many additional Shopping queries to make.

A strong first response can end the search after one request. Partial results get one additional query. Sparse results can get two. The code records the request count and strategy, then removes duplicate products across the result groups.

That is a concrete cost-control decision: spend on another search when the first response needs help. Actual savings depend on the mix of results; I have not measured an average saving across production searches.

A metered action has a lifecycle: reserve credits, run the action, then mark usage complete. If the action throws, the error path attempts to refund the reserved usage before returning the failure.

The request ID ties that lifecycle together. It gives the system a way to account for the action beyond a loading spinner on the phone, including when a provider fails to return a result.

Outfittr is live on the App Store. After launch, I kept working on the moments that interrupted the experience, from onboarding to uploading photos.

Shipping made it real. Maintaining it means paying attention to the places where someone’s experience can still break.