April 2026
DavisDine shows UC Davis students what's in the dining commons today. You filter by allergen, and then you build a plate that adds up the calories and macros across every single station you happened to pull a dish from. Before it existed, working out what I could actually eat meant clicking through a slow campus menu portal for a couple of minutes at every meal, which honestly got old faster than you'd think. I wanted five seconds instead. It's on the App Store.
Here's the core loop, running right on this page. Turn off an allergen and anything that contains it drops straight out of the list below. Tap a few dishes, watch the plate fill in, and the totals shift as you go. Why bother filtering at all? Because a student with a real allergy otherwise has to read through every ingredient label by hand, at every meal, forever, and that is exactly the chore the app is built to kill.
The sample menu uses the same shape the app does. The real one pulls today's actual stations.
The front end is SwiftUI on iOS and Jetpack Compose on Android. Behind it sits a FastAPI service on Google App Engine, with Firestore underneath for storage. A cron job scrapes the UC Davis menus, pushes each batch through Claude Sonnet to sort the items into twelve cuisines at a hundred and fifty per call, and caches whatever comes back, so all the expensive work lands at scrape time instead of the moment a hungry person opens the app. A request is just a Firestore read. The app holds a local copy too, so it still works with no signal.
I regret the social layer more than anything else I shipped. I wrote chat, threaded replies, the whole helpfulness-voting thing, before I had bothered to check whether one single student actually wanted any of it. None of them did. They pretty much came to look at a menu fast and plan a meal, nothing more, so I pulled most of that code back out inside two weeks. Old lesson, learned again: ship the smallest thing that solves the real problem, then wait for people to pull on it before you build anything else on top.
Cost was the other miss. About a month in, the Cloud bill jumped. A dev dashboard had been polling in a tight loop the entire time, and the instance was probably a size bigger than the workload ever actually needed. Setting min_instances to zero and moving the cron from every fifteen minutes down to hourly sorted it in an afternoon. To be fair, a billing alert wired up on day one would have caught the whole run-up in hours, not three weeks.
It's live on the App Store, and students use it daily to plan around allergens and macros. The backend scales down to nothing when nobody is hungry, so running the entire thing costs less than a single meal swipe a month.