Inspiration
Restaurant managers order stock and schedule prep largely on gut feel — a habit that quietly produces food waste on slow nights and stockouts on busy ones. For "Forward: AI in Business Hackathon," we wanted to see whether the signals a restaurant already has on hand — day of week, weather, upcoming reservations, nearby events, holidays, active promotions — were enough for a lightweight model to answer one concrete question: how many of each menu item will actually sell today?
What it does
MiseCast is a dashboard where a manager picks a date and gets back the expected number of units sold for each of the 15 menu slots. Behind the scenes it pulls in the day's context — weather at the restaurant's location, public holidays, nearby events, confirmed reservations — assembles that into a feature row, and hands it to a trained demand model. If any one of those external lookups fails, the dashboard automatically falls back to a clearly labeled simulation mode for just that source instead of failing the whole prediction.
How we built it
Three pieces, three owners, wired together over HTTP:
ml_pipeline/— pandas for feature engineering against our data schema, and a scikit-learnRandomForestRegressor(native multi-output, so one model predicts all 15 menus at once). Trained on our historical dataset with a time-based holdout split, landing at an overall MAE of 2.83 units/menu/day.api/— a small FastAPI service that wraps the trained model behind/predictand/retrain, kept independent of the database so it can be tested and deployed on its own.backend/— the Node/Express/EJS/MongoDB dashboard itself: calendar, weather, reservations, menu, and import views, calling the FastAPI service for predictions.
We deployed on a teammate's Google Cloud credits, running the stack on a VM, after starting out on MongoDB Atlas's and Render's free tiers.
Challenges we ran into
- A contract drift between our two services. The dashboard and the ML pipeline were built in parallel by different people. The placeholder model we integrated against early on returned predictions as flat
menu_1_amount-style keys; when we wired in the real trained model, it turned out to return the same data nested under apredictionsobject. The mismatch only showed up once we actually pointed the dashboard at the real model. - Infra churn on free tiers. We paused MongoDB Atlas and Render mid-hackathon and pivoted to a teammate's Google Cloud VM, which meant re-checking assumptions like network binding and environment configuration that Render had handled for us.
- A two-table data schema. Our source data ships as two separate tables joined by
_id, padded with repeated rows per day — collapsing that back to one row per date (without silently hiding real data disagreements) took more care than a single flat CSV would have.
Accomplishments that we're proud of
- Getting the real trained model live behind the dashboard's predict button — not a stand-in — at MAE 2.83 units/menu/day.
- Building an automatic, transparent fallback (simulation mode) so the dashboard keeps working, and says so, when a weather/holiday/event/reservation lookup fails.
- Getting three independently built pieces — a Python ML pipeline, a FastAPI service, and a Node dashboard — talking to each other correctly under a hackathon deadline.
What we learned
- Pin down the API contract (exact response shape, example payloads) before two people start building against it in parallel — a nested-vs-flat JSON mismatch is a small diff but a full integration break.
- Graceful, clearly disclosed degradation is worth more under a deadline than chasing zero downtime on every external dependency.
- Free-tier cloud services are great until they aren't — it's worth having a pivot plan for infra early rather than mid-hackathon.
What's next for MiseCast
- Training on real restaurant sales data — what we have now is shaped like a real export but is still synthetic.
- Live external feeds (an actual weather forecast API, a live reservation system) instead of point-in-time lookups.
- Confidence intervals around each prediction instead of a single point estimate.
- Hardening the deployment (network configuration, monitoring, error handling consistency across routes) beyond what a hackathon demo needs.
Log in or sign up for Devpost to join the conversation.