Diego Rodríguez Piñeiro

In Styl-AI-Closet, I was the sole software engineer that built the app that would connect to the hardware (ESP32). I built the Flutter frontend and a FastAPI backend with 30+ endpoints backed by MySQL, plus a WebSocket layer for real-time state, RBAC for user/admin permissions, and the ESP32 integration that drives the physical rail. The name reflects the product concept; the current build focuses on the real-time control and delivery system rather than an ML component. The app has a login system that would allow a user to sign up to their closet. This app allows them to scan pieces of clothing that they had and display them in the digital closet inside the app. The user also had the option to add clothing to the physical closet and display it in the app and this would let the hardware know that a spot in the closet is taken by said garment. If the user decided to take out a piece of clothing the rail would rotate and display the selected garment in front of the user so he could take it. The app would then notify the user that the delivery has been made and that it was taken out of the designated slot.

A major problem encountered was safeguarding the hardware system from overloading with commands or stopping if 2 users shared the same physical closet. I didn't want to let both commands through, since the physical rail can only be in one place, and I couldn't have each app track its own state, because then the two users' mobile apps would disagree with the current state of the rail and closet. To counter this I used a WebSocket layer so the server held the single source of truth of the closet's state, when one user took control and sent a command, the other user was locked and put in queue to send a new command to the closet. This allowed for real-time updates to each user of the closet. This resulted in being able to have multiple users that all saw the updates and accurate state of the closet without sending contradicting commands.

• →Sole software engineer on the project: Flutter client, 30+ endpoint FastAPI backend, MySQL schema, and the ESP32 integration layer
• →Solved a real concurrency problem in hardware: server-authoritative state over WebSockets with command locking and queueing, so two users can't send the physical rail contradicting commands
• →Designed RBAC user/admin permissions and treated every feature's auth surface as part of the design, not a later pass

This project uses a 100,000-patient dataset to predict diabetes diagnosis, applying all three ML paradigms: supervised classification, unsupervised clustering, and deep learning. Before training anything, I made a deliberate leakage and framing decision: two columns (diabetes_stage, diabetes_risk_score) are pure leakage, derived directly from the diagnosis itself, so I dropped them outright. Four more (HbA1c, fasting glucose, postprandial glucose, insulin level) are legitimate clinical diagnostic markers rather than leakage in the strict sense; I excluded them on purpose to frame the model as a pre-lab screening tool: could diabetes risk be flagged from lifestyle and demographic data alone, before a patient ever gets bloodwork?

That framing is why every supervised model converged in a tight 0.64-0.66 AUC band rather than scoring much higher, a direct consequence of excluding the strongest predictors on purpose, not a data limitation. Across Logistic Regression, Decision Tree, Random Forest, and Gradient Boosting, Logistic Regression had the best ROC-AUC (0.659) and Random Forest the best F1 (0.736); 5-fold cross-validation confirmed the results were stable. In this labs-excluded setting, the strongest predictors were family history of diabetes (feature importance 0.37, more than triple the next feature), age (0.21), physical activity (0.13), and BMI (0.09).

Unsupervised clustering (K-Means and Agglomerative, k=2-10) found no tight natural subgroups; silhouette scores stayed low and 2-component PCA captured only 20% of variance, but it did surface a risk gradient: a higher-risk cluster (older, higher BMI and blood pressure, less active) showed a 65.8% diabetes rate versus 54.5% in the lower-risk cluster. Notably, family history barely differed between clusters, suggesting genetic and lifestyle risk act as largely independent factors. A 3-layer PyTorch network (batch norm, dropout, early stopping) reached 0.658 AUC, matching the classical models despite far more complexity, consistent with deep learning rarely beating simpler models on tabular data with limited signal. The practical recommendation: deploy Logistic Regression and route high-scoring patients directly to confirmatory HbA1c testing.

• →Distinguished genuine leakage (columns derived from the diagnosis) from diagnostic markers excluded deliberately to frame the model as a pre-lab screening tool
• →0.66 AUC is a designed ceiling from that framing choice, not a data flaw: a decision I can defend end to end
• →Family history emerged as the dominant predictor (0.37 importance, 3x the next feature), yet was flat across lifestyle-based clusters: genetic and lifestyle risk behave independently