The
Baker.
Smart Retail Operations Platform
A production-grade full-stack application that bridges the gap between Customer Experience (CX) and Operational Efficiency. It solves the "Small Bakery Paradox": balancing demand volatility with the high cost of food waste.
The Problem
Small bakeries face two critical failures:
1. Customer Friction: Unsure if open, no inventory visibility, wasted trips.
2. Operational Waste: Over-production due to lack of data.
The Solution
A unified Hybrid Monolith platform:
Customer Portal: A Real-time PWA for live stock visibility and reservations.
Staff Dashboard: An AI-assisted decision support system recommending daily production levels.
The "Dual-Core" Prediction Logic
Dynamic Regression
Objective: Predict Sales Velocity ("How many can we sell?").
- • Day of Week: One-hot encoded vectors (Saturday_Boost).
- • Weather: Categorical mapping (Rain, Snow) to impact coefficients.
- • Logic: Base Bias + Weighted Coefficients = Dynamic Target.
Sparse Data Handling
Objective: Quantify Inventory Risk ("Probability of over-production?").
Standard regression treats waste as outliers. My solution:
- • Active-Day Filtering: Isolates days where production > 0.
- • Risk Score: Calculates Average Loss per Active Day vs. Velocity.
- • Analyst Note: Waste is operational variance, not linear weather function.
Tech Stack
- Backend: Java 17, Spring Boot 3.2
- Data Science: Python 3.x, Pandas, Scikit-Learn
- Frontend: Thymeleaf (SSR) + TailwindCSS
- Database: H2 (Dev) / PostgreSQL (Prod)
- DevOps: GitHub Actions (CI) → Render (CD)
Key Capabilities
"What-If" Simulation Engine
Staff can manually override weather parameters (e.g., switch "Sunny" to "Rain"). Triggers in-memory vector recalculation (O(1)) without model retraining (O(N)).
Mathematical Transparency
Rejects "Black Box" predictions. The UI decomposes recommendations into constituent weights so staff trust the AI.
Prediction = Base (10) + Saturday (+2) + Rain (-1) = 11 Units
Automated Pipeline (CI/CD)
Just-in-Time Training: Python training script runs as a pre-build step in GitHub Actions. Ensures inference weights are always synchronized with the latest sales snapshot before deployment.