Overview
To contribute to my parent's new and growing restaurant business, I built the backend, a staff dashboard, and a native iOS app, choosing one REST API as the shared source for business logic and data. The system supports order tracking and analytics, with historical orders feeding seven-day demand forecasts.
What it is
Staff use the web dashboard to manage and track orders and review business analytics. Customers use the iOS app to browse the menu, build a cart, check out, and review order history.
The clients share the same backend, which handles restaurant workflows and keeps order data consistent across the dashboard and app.
Why I built it
I wanted a project that forced me to think beyond a single screen or a single language. Restaurants have a natural split between operations (staff) and customers (mobile), which made it a good domain for practicing API-first design.
Building the backend, web client, and iOS app as one system taught me where complexity actually lives in full-stack work—usually at the boundaries between layers while contributing something to my parent's new and growing restaurant business.
Architecture
The backend is a Flask-powered REST API that owns all business logic, validation, and data storage with SQLite. Neither the web dashboard nor the iOS app talks to the database directly—everything flows through the API.
That separation made it possible to develop and test each piece independently, and it mirrors how production teams structure multi-client products.
What I worked through
On the backend, I modeled restaurant workflows in SQLite and built Flask endpoints for order processing, menu management, and business analytics. The iOS client calls the same API through native Swift with async/await, using SwiftUI views for the menu, cart, checkout with MapKit location, and order history.
I also integrated statistical forecasting into the analytics pipeline: ARIMA models trained on historical orders to predict 7-day demand, with accuracy metrics validated against actuals. Getting three layers—backend, web dashboard, and mobile—to agree on data shape, error handling, and edge cases was as valuable as any individual feature.
Lessons learned
The biggest lesson was where complexity actually lives in full-stack work. It is rarely in a single feature—it is at the boundaries between layers. Getting a web client and an iOS app to agree on the same API contract taught me to think about data shape and error handling as shared responsibilities, not backend-only concerns.
I also learned the value of API-first design as a development strategy, not just an architecture pattern. Defining the contract before building clients meant I could work on each layer independently and have confidence they would integrate cleanly. That discipline pays for itself the moment requirements change.
Highlights
- Designed an API-first architecture where a single REST backend serves 2 client platforms (web dashboard and native iOS)
- Built a REST API with validation, business logic, and persistent storage for order and analytics data
- Delivered a web dashboard giving staff real-time visibility into orders and business performance metrics
- Developed a native iOS application integrated with the shared backend for the customer-facing experience
- Practiced cross-layer problem solving by aligning data models, API contracts, and client behavior across 3 codebases