Campus dining information
2024 · Completed yearlong project
DC Menu App
Bringing four fragmented dining menus into one student workflow
As an application developer on a cross-functional CodeLab team, I helped build a React Native app that brought UC Davis dining locations, menus, dietary details, favorites, and macro tracking into one place.
Quick scan
TL;DR
The shortest version: what changed, what shipped, what was verified, and where the proof stops.
Overview
Problem
UC Davis dining information was split across four separate sites, making it cumbersome to compare locations, meal availability, dietary options, ingredients, and nutrition.
Move
Organized the experience around a student’s immediate questions—where can I eat, what is available now, and does it fit my needs—then connected the interface to scraped menu data.
Outcome
Completed a mobile workflow with dining-location status, meal periods, dietary filters, detailed menu records, favorites, macro tracking, CRUD APIs, and Google authentication.
Scope
Application development within a yearlong, cross-functional CodeLab project spanning research, design, data ingestion, backend services, authentication, and React Native delivery.
Proof
- Information surface
- 4 dining commonsThe app joined the four separate UC Davis dining destinations into one mobile overview.
- Addressable segment
- ~9,000 studentsThe team estimated the initial meal-plan audience; this is not an adoption metric.
- Delivery window
- 22 weeksThe published article records a yearlong team project spanning 22 working weeks.
- Data path
- 4 layersBeautifulSoup, MongoDB, Express, and React Native separated acquisition, storage, API, and presentation.
01 · Context
One dining decision required navigating four separate sources.
The UC Davis dining-commons website separated each location into its own destination. Students had to move between sites to compare what was open, which meal was being served, and whether an item matched a dietary preference or nutrition goal.
The team estimated that roughly 9,000 freshmen and transfer students with meal plans formed the most relevant initial audience. That figure describes an addressable campus segment, not measured app adoption.
Research combined competitor analysis with student interviews and surveys. Comparable dining apps consistently exposed locations, operating hours, and meal categories, while students with irregular schedules made exact service times especially important.
02 · The decision
Start with the decision a student is trying to make right now.
Choose a location. Check the meal window. Filter what fits. Inspect the details.
The interface put all four dining commons on one home screen, paired each location with its operating state, and carried students into breakfast, lunch, or dinner menus with explicit time windows.
Dietary filters for vegetarian, vegan, halal, and lower-calorie choices sat directly in the menu flow. Expandable food records exposed serving size, calories, macronutrients, allergens, and ingredients without forcing every item into the densest possible view.
Favorites and macro tracking extended the experience beyond discovery. Students could save foods and assemble a daily view of what they had consumed rather than treating nutrition information as a static reference.
Product noteTime is part of menu relevance.
The research moved the product beyond generic breakfast, lunch, and dinner labels by preserving the actual serving window for each station.
- The home view exposes location status before a student opens a menu.
- Meal tabs separate breakfast, lunch, and dinner.
- Station sections pair offerings with exact service times.
03 · What shipped
A mobile client sat on top of an inspectable menu-data path.
A Python scraper using BeautifulSoup extracted menu items, nutrition values, allergens, and ingredients from the existing dining site. MongoDB stored the resulting records, while Node.js and Express exposed CRUD routes for the React Native client.
The front end combined that data with dining-location navigation, search and dietary filters, saved items, and daily nutrition tracking. The team also added Google authentication and iterated on accessibility and device responsiveness.
The published project record demonstrates the implemented interface and backend data shape, but it does not establish a public launch, active-user count, retention, or student-outcome improvement.
Track a day
Inspect the data
Engineering noteThe pipeline separated acquisition, storage, API, and presentation.
Each layer had one clear job, making the menu source and the mobile experience easier to reason about independently.
- BeautifulSoup extracted current dining-site data.
- MongoDB stored structured menu and nutrition records.
- Express exposed the records through API routes.
- React Native rendered the student-facing workflow.
04 · Evidence
The defensible result is a completed team build, not campus adoption.
The CodeLab article documents a 22-week project, names the cross-functional team and technology stack, shows high-fidelity product screens, and describes the scraper, database, Express API, CRUD routes, React Native interface, and Google authentication work.
The roughly 9,000-student figure comes from the team’s market analysis of freshmen and transfer students likely to hold meal plans. It is therefore presented as an addressable segment rather than a user, launch, or reach metric.
The source does not publish usage analytics, reliability data, accessibility results, scraper freshness, or outcome measurements. Those claims remain outside this case study.
05 · Reflection
Dependency changes deserve the same coordination as product changes.
Late in the project, an accidental Expo upgrade from SDK 49 to SDK 51 deprecated components and disrupted previously stable work. The recovery made version control, dependency pinning, and upgrade review concrete team responsibilities rather than background setup.
The project also required coordination across a large student team with conflicting schedules. Hybrid meetings and asynchronous updates kept work moving, but clearer ownership and smaller integration checkpoints would have reduced the cost of late surprises.
A stronger next iteration would add scraper health monitoring, data-freshness indicators, accessibility testing, and behavioral measurement around menu discovery and dietary filtering.