AI Mobile Outfit Try-On

The problem

A solo consumer founder had a thesis: that the friction in online clothing shopping wasn't price or selection but the inability to see how something would look on you before buying it. The category had been tried before — most attempts had been clunky 3D try-on tools that required body scans, expensive integration, or both. The founder thought the new generation of image models had closed that gap. You could now generate a credible image of a person wearing a specific garment from two inputs: a photo of the person, and a photo of the garment.

The question wasn't whether the thesis was true. The question was whether it was true enough to bet on — whether the generated images were credible enough that a real shopper would trust them. Building a full product to answer that question would have taken six months. The founder had eight weeks before they planned to raise.

They needed proof, not product.

The cut

The scoping call landed on the smallest possible version of the demo: a mobile-first interface where a user could upload a selfie, upload (or paste a URL of) a garment, and see a generated image of themselves wearing it. No e-commerce integration. No catalogue. No accounts. No saved looks. Just the core loop, end-to-end, with a real generation pipeline behind it.

What got cut: the catalogue (the founder had wanted to seed it with 50 partner brands — none of which were locked down; we cut all 50). User accounts and history (a session-only flow was enough to prove the thesis). The web version (mobile-first only — the demo would never be tested on desktop). Payment, even as a placeholder. Anything that wasn't directly answering the question are these images credible enough to convert a shopper?

The hardest cut was the share function. The founder wanted users to be able to share their try-on results to social. It was a reasonable ask — viral loops are valuable, especially pre-launch. But the share function would have eaten three days of the one-week MVP and added nothing to the core question. We deferred it to the beta. It shipped in week three.

The build

Stack: React Native for the mobile app, Supabase for storage and auth, Replicate to host the image-generation model, with a thin wrapper layer for the prompt construction and image preprocessing. Mobile-first meant mobile-only for the MVP — no web fallback, no responsive desktop view.

Week one was the entire MVP. Day one was setup and the image-upload flow. Day two was the generation pipeline — getting Replicate calls working with the right model, with the right input preprocessing (cropping, resizing, masking), and with enough error handling that a failed generation didn't kill the user's session. Day three was the UI: upload screen, generate screen, result screen, and a single retry button. Days four and five were the parts that always take longer than expected — handling the variability in input photos, dealing with the model's failure modes, and tightening the prompt template until the success rate was high enough to be worth shipping.

By Friday of week one, the loop worked end-to-end. About 70% of generations produced an image the founder considered credible. The other 30% were failures we could now name — bad lighting in the source photo, garments shot at angles the model couldn't infer the back of, full-length poses where the model lost the face.

Weeks two through four were the path to beta. The success rate climbed from 70% to 88% over those three weeks — most of the improvement came from input validation (rejecting selfies that wouldn't work before the user wasted a generation on them) and from a second model swap to one with better fashion-domain coverage. Week three added the share function. Week four hardened the auth, added analytics, and got the app through TestFlight review.

Beta launched on day 28, on schedule.

What happened next

The beta did what it needed to do. A small group of testers used it, the conversion question got an early answer (positive — testers who liked the generated images were significantly more likely to say they'd buy the garment), and the founder went into their raise with usage data and a working product instead of a pitch deck.

What we didn't ship in the Sprint, on purpose: any of the connective tissue that would turn this into a business. No catalogue, no checkout, no partner integrations. That was the right call for the Sprint and the right call for the proof, but it left the founder with a clear next phase — and they hired separately for it. Our engagement ended cleanly at the beta launch, with handover docs and a codebase the next team could pick up without rewrites.

The MVP itself is still live as the beta product. It hasn't been rewritten. Some of the prompt engineering and preprocessing logic from week one is still in production.

The lesson worth naming: shipping in one week isn't about doing more work faster. It's about knowing — with conviction — what doesn't belong in week one. Beta in four weeks isn't the achievement. The achievement is the discipline that decides what to leave out of week one. Everything else follows from that.