Aditi’s
Wardrobe.
Helping my mom choose from 100+ sarees, with a memory of what she wore and who saw it.
The story in brief
I built Aditi’s Wardrobe for Lovable’s Mother’s Day hackathon as a gift for my mom. I owned the PRD, MVP scope, build, and iteration, with my mom as the tester.
Remember which sarees she wore, and who saw them.
Reduce the work of cataloguing, logging, and choosing.
A shipped app, refined with one real user.
Validation so far is qualitative feedback from my mom. Broader adoption and willingness to pay are still untested.
Finding the real problem
My mom owns 100+ sarees. Before a wedding, puja, or dinner, she searches years of photos to remember what she wore, when, and who was there.
The decision depends on the people attending, not just the last time she wore an outfit. That made wear history and guest overlap central to the product.
Before this event, which sarees can I wear without repeating one in front of the same people?
I scoped the MVP around that question: a visible collection, a record of each wear, and a way to check an upcoming guest list.
Scoping the MVP
Three screens support one decision.
1. Wardrobe
Catalogue the collection with photos and automatically generated tags.
2. Log Outfit
Record the event, date, and people present.
3. Plan Event
Compare an upcoming guest list with past wears to surface suitable outfits.
The repeat check depends on recorded history. Missing wears or guests can leave gaps, so “safe to wear” is a guide based on what has been logged.
Decisions & tradeoffs
| Decision | Reasoning | Tradeoff / open question |
|---|---|---|
| Remove login | I watched my mom stall at sign-up and removed that step. | Before expanding, I need to assess how access, privacy, and recovery should work without adding that friction back. |
| AI tags & names | GPT-4o vision reduces manual entry when adding a saree from a photo. | Generated descriptions may need correction. Accuracy and correction effort still need testing. |
| Guest-based repeat check | The relevant context is who has seen an outfit before. | The recommendation is only as complete as the recorded wear history and guest lists. |
| Pixel-art visual style | The design connects with my mom’s 2000s computer nostalgia and personal style. | A style that works for her may not work for a broader audience. |
What testing changed
My mom’s reactions shaped the product after the first build.
Sign-up became a stopping point
Observed: She stalled at the authentication screen.
Changed: I removed login entirely.
Wear history became a memory feature
Observed: She enjoyed revisiting past wears.
Changed: I added a History timeline.
The visual direction needed iteration
Changed: I ran several design passes until the interface felt like something she wanted to open.
My strongest learning: for this user, reducing friction mattered more than adding features.
What I would validate next
The next step is to share the app with my mom’s friends and see whether the same problem—and the same solution—holds beyond one person.
- Can people get to a useful collection?
- Observe where they stall while adding outfits. Track time to a first catalogued saree and the effort needed to correct AI tags.
- Does event planning help?
- Watch someone plan a real event. Check whether the guest-based recommendation helps them choose an outfit.
- Will people maintain the history?
- Check whether they log later wears and return before another event. The repeat check needs an up-to-date history to remain useful.
These are proposed validation questions, not measured results.
Further ideas include lehengas and salwar suits, plus a worn-count badge to surface favourites and neglected pieces.
A path beyond one user
My starting audience hypothesis is South Asian women aged 40+ with large saree collections, with daughters potentially helping them set up the app.
- Positioning to test
- “The anti-repeat wardrobe app for saree owners.”
- Distribution hypotheses
- Start with my mom’s friends and family WhatsApp groups. Later, test saree styling and resale communities on Instagram and wedding-season content.
- Pricing hypothesis
- A free first set of outfits, with a small annual fee for an unlimited collection and event planning. Willingness to pay is untested.
How I built it
I used Lovable to ship the app, with TanStack Start, React, TypeScript, and Tailwind CSS; Lovable Cloud (Supabase) supports the backend. GPT-4o vision powers photo-based tagging.
- Lovable
- TanStack Start
- React
- TypeScript
- Tailwind CSS
- Lovable Cloud (Supabase)
- GPT-4o Vision