AI Mobile Outfit Try-On

Day one

What existed when we started: Figma designs for the app, and nothing else. No code, no repository, no model chosen, no generation pipeline, no decision on whether the thing was even possible at acceptable quality. The designs were good and they were not the hard part.

The founder was solo, and had a thesis: that the friction in online clothing shopping was not 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 was not 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. The core loop, end-to-end, with a real generation pipeline behind it. Nothing else.

What we cut, and why:

• The fifty-brand catalogue. The founder wanted the MVP seeded with fifty partner brands. None of the fifty were locked down. Building a catalogue around partnerships that do not exist yet is building the wrong thing twice. All fifty cut.
• User accounts and history. A session-only flow answered the question. Auth is a week you spend on plumbing rather than on the thing under test.
• The web version. Mobile-first meant mobile-only. The demo would never be tested on desktop, so a responsive desktop view was work no one would look at.
• Payment, even as a placeholder. A checkout that cannot take money is a screenshot with extra steps.
• The share function. The hardest cut, and the founder's favourite. Sharing try-on results to social is a reasonable ask — viral loops are valuable, especially pre-launch. But it would have eaten three days of a one-week MVP and added nothing to the question are these images credible enough to convert a shopper? Deferred to the beta. It shipped in week three, which is the point: cutting something in week one is not refusing to build it.

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 prompt construction and image preprocessing.

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 did not 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 could not infer the back of, full-length poses where the model lost the face.

Weeks two through four were the path to beta. The credible-output rate climbed from 70% to 88% over those three weeks — most of the improvement came from input validation (rejecting selfies that would not 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.

What happened next

We do not publish a client's business outcomes without written clearance, and we do not have it for this one. What the founder did with the beta, what the raise did, and what the testers converted at are theirs to disclose, not ours.

What we can say is about the engagement and the code. The beta shipped on day 28 and the engagement ended cleanly there — handover docs, and a codebase the next team could pick up without rewrites. We did not ship any of the connective tissue that would turn this into a business: no catalogue, no checkout, no partner integrations. That was deliberate, it was agreed on the scoping call, and it left a clear next phase that the founder hired for separately.

The MVP itself is still live as the beta product. It has not 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 is not about doing more work faster. It is about knowing — with conviction — what does not belong in week one. Four weeks is the number we commit to. This build did not need all of it, and that is the right way round: a commitment you beat is worth more than an average you miss.