Recommendation / retrieval
StyleSync
A fashion recommendation system extended from a hackathon concept into a two-tower retrieval stack with public serving surfaces.
StyleSync is interesting to me because it shows a different kind of engineering growth than the more systems-heavy projects on this site. It began as a quick hackathon build called Mirror, then became a more deliberate recommendation workflow once the underlying idea proved worth keeping.
Problem
The original question was simple: can a user look at an item on the web and quickly surface visually similar alternatives? Solving that cleanly required more than a frontend demo. It needed a trainable retrieval setup, candidate generation, deployment surfaces, and a serving path that could respond predictably instead of just returning one-off search results.
System shape
The project was extended into a two-tower retrieval pipeline built with TensorFlow Recommenders. A user tower learned a retrieval representation from transaction history, while an item tower learned the catalog side that could be exported and indexed. Candidate generation then moved through FAISS, and the project grew a FastAPI backend plus a Streamlit front end for public interaction.
Architecture diagram
The useful shift was turning a browser-side idea into a retrieval system with a trainable user tower, an exportable item tower, an ANN index, and separate frontend and backend surfaces.
Dataset and artifacts
The retrieval stack was built around the H&M Kaggle dataset, using at minimum
transactions_train.csv and articles.csv, with optional customer metadata and
precomputed image features. The repo also supports optional ResNet50 image embeddings so image-side
signals can be folded back into training and export rather than treated as a separate demo path.
Evaluation snapshot
| Component | What I used | Public proof on the site |
|---|---|---|
| Retrieval model | Two-tower recommender built with TensorFlow Recommenders | Moved the project beyond a browser-only prototype into a trainable retrieval setup. |
| Dataset | H&M Kaggle transactions and article catalog | Made the project reproducible instead of depending on ad hoc product examples. |
| Indexing | FAISS ANN index for item lookup | Turned embeddings into fast nearest-neighbor search rather than one-off similarity checks. |
| Serving | FastAPI backend on Render plus Streamlit frontend | Made the project easy to try directly instead of leaving it as a local-only prototype. |
| Artifacts | faiss.index, item_ids.npy, exported user and item towers |
Shows the retrieval system was packaged as a reusable serving artifact, not only a training run. |
| Image pathway | Optional ResNet50 image embeddings | Kept the project connected to visual inputs instead of reducing it to pure tabular retrieval. |
What changed after the hackathon
The part that mattered most after the hackathon was deciding what deserved to survive. The browser interaction idea stayed, but the project became more serious once the retrieval model, FAISS index, and serving layer were explicit parts of the design. That is when it stopped being “Gemini plus shopping links” and became a recommendation system with a clearer technical center.
Live surfaces
The repo now exposes a Streamlit app for the user-facing flow and a FastAPI service on Render for the recommendation endpoint, including a public docs page. That matters because it turns the work into something a recruiter or engineer can click through instead of only read about.
Why it matters
This project is useful proof that I can take a fast idea and decide whether it deserves a second life. Not everything from a hackathon should become a full project, but when something does, the engineering challenge becomes deciding what survives the jump.