Get Dressed

What was the idea?

Digitalize the wardrobe. Photograph the piece lying on the floor, have the background removed, have the image labeled by AI for color, brand and type, and every morning receive one outfit, pictured as the combined look. The app takes one decision off the morning.

The sketch leads with AI; the build led with the foundation that AI stands on: real accounts, a real catalog, clean images. That foundation is built and working: items with photos, categories, colors, brands and sizes, outfits composed from them, daily plans on the calendar, friends and a posts feed around it all. The AI half is the roadmap: background removal, automatic labeling and outfit matching by color.

How does an item get from camera to closet?

Pick or shoot a photo, name the piece, file it under category, color, brand and size. The upload goes up as multipart and comes back processed server-side, so the wardrobe grid, search and outfit composer all run on clean images. Sixteen route modules cover wardrobe, outfits, daily plans, settings, privacy, friends and posts, and every guarded one of them wants a bearer token.

Why does a wardrobe app carry its own backend?

Firebase was ruled out on taste, so the backend got written: the Express API owns auth with bcrypt hashing and JWT bearer tokens, the MySQL schema with 17 tables from wardrobe_items to post_likes, and the image pipeline. One repo, one data model, both halves versioned together, and a friend with a phone can actually register, add a shirt and show up in your feed. The taste has moved on since: the same slot today would probably get Postgres, Redis and BullMQ.

How does the morning suggestion work?

The server groups what you own by category and composes each suggestion one piece per category, with at least a top and a bottom required before it counts as an outfit. The pick lands on the home screen as the day's card, and the calendar stores which outfit is planned for which date.

The next step for that engine is matching: color rules, so only fitting combinations reach the morning card.

What did building it twice teach?

The method: little proofs of concept first, glued together into something that runs, then a clean rebuild that applies every lesson at once. The second pass is faster and lands cleaner, because the lessons are already paid for. On a project you intend to keep, build it twice.

Here that meant moving the client onto MVVM layers while it kept working: a core layer for auth, networking and navigation, a data and domain split behind repository interfaces, dependency injection through get_it, viewmodels per feature, one router, and the data layer under unit test. The server kept its shape; the client got the discipline.

What happens next?

Development runs in two layers right now. A hardening pass first, across both halves of the app. Then the AI features from the original sketch: background removal on item photos, automatic labeling for color and brand, color-rule outfit matching and the combined-look preview for the morning card.

The ML half has a sibling in this portfolio already: clothingrecognizer, the ML pipeline that strips, recognizes and files clothes. The wardrobe gives it the closet; it gives the wardrobe the eyes.

Field notes

• 177 Dart files, ~30,200 lines on the client; 29 files, ~6,750 lines of Express on the server.
• 17 MySQL tables: wardrobe_items, outfits, outfit_items, daily_outfits, friend_requests, friendships, posts, post_photos, post_likes, post_comments, plus the user, settings and privacy tables around them.
• 35 unit tests across 3 repository suites.
• Every wardrobe, outfit, daily-plan, friends and posts route is JWT-guarded; items are searchable by name and filterable by category.
• Built in about a month, restructured onto MVVM along the way, in active development today.