<aside> ❓
Why the shared systems matter for this project
FitCheck was built by team members working independently on four services — Wardrobe, Outfit Sharing, Marketplace, and AI Stylist. Without a set of shared systems, the result would have been four apps that each stored clothing differently, tried on garments differently, and treated privacy differently, loosely connected by a shared navigation bar.
The systems documented here were agreed collectively and apply across all four services. Individual portfolio pages show how each designer applied these systems inside their own service. This page documents what was agreed, what was built, and why.
</aside>
<aside> 💡
Note on scope
A garment in FitCheck doesn't belong to one service — the same pair of sneakers is an item in the Wardrobe, a listing on the Marketplace, an outfit on a shared profile, and an input to the AI Stylist. Every system on this page exists because the same object has to behave consistently no matter which service is looking at it.
</aside>
Every service reads, creates, and uses clothing items, so clothing has to be formatted the same way everywhere. The Clothing Database is the single schema all four services share — one item, one shape, one source of truth.
We made a foundational decision for three reasons specific to FitCheck's context.
First, an item is created once and consumed everywhere. A user adds "White Sneakers" in the Wardrobe; the Marketplace lists it, Outfit Sharing displays it, and the AI Stylist reasons about it — all from the same record. If each service kept its own copy, editing the size would mean editing it four times.
Second, the same fields drive different features. Size powers marketplace filtering, Material powers try-on rendering, Purchased powers "cost per wear" analytics. A shared schema means a field added for one service is immediately available to the others.
Third, a consistent shape keeps the UI consistent. Because every item carries the same fields, the item card looks and behaves the same whether it's opened from the Wardrobe or the Marketplace.
Standard item schema
| Field | Example | Used by |
|---|---|---|
| Brand | Common Projects | Marketplace, AI Stylist |
| Size | US 9 / EU 42 | Marketplace, Try-On |
| Color | White | AI Stylist, Outfit Sharing |
| Material | Leather | Try-On, AI Stylist |
| Purchased | March 2025 | Wardrobe analytics |
| Tags | Shoes · Casual · Summer | All services |
| Visibility | Private / Public | All services (see System 3) |
Every item card exposes the same three actions: Edit, Try On, Sell. The action set is constant; each service simply decides which actions are enabled in its context.
Try-on is featured across multiple services — trying on your own clothes in the Wardrobe, or trying on a garment before buying it in the Marketplace. Because the entry points differ but the experience must not, try-on is built once as a shared system and called by whichever service needs it.
We built it as a shared flow for three reasons.
First, the input is always the same: a real-world capture (point your camera at your feet / body), a detection step, and an overlay of the selected item. Rebuilding that pipeline per service would produce three subtly different try-on experiences.
Second, it operates on the shared Clothing Database. Try-on renders from the item's Material, Color, and category, so any item — owned or for sale — can be tried on without special handling.
Third, trust depends on consistency. A user deciding whether to buy needs the marketplace try-on to feel exactly as accurate as the try-on they already trust in their own wardrobe.
Shared flow states