DevDine Restaurant
A food-delivery marketplace built around three distinct user roles: diners, restaurant owners and delivery riders, each with its own authentication portal and dashboard.
Tech Stack
The Challenge
A delivery marketplace is really three products sharing one database. A diner wants to browse and order. A restaurant owner wants to manage a menu and incoming orders. A rider wants assignments and a phone-based login, not an email one. Modelling that cleanly from the start is the difference between a demo and something extensible.
The Solution
Built with Next.js and MongoDB. Instead of bolting roles onto a single user model, each role gets its own entry point and its own dashboard route, so the diner-facing storefront stays lean while the owner and rider tooling can grow independently.
One small detail mattered more than it looks. Riders authenticate by phone number, not email, because a phone is what delivery workers actually have to hand. Matching the credential to the person, not to the schema, often decides whether a flow gets used at all.
Current state
The application shell, routing and all three auth flows are complete. The restaurant catalogue isn't seeded yet, so the live deployment shows an empty storefront. Look at the architecture here, not the content.
Key Features
- ▸Three separate authentication portals with role-appropriate credentials
- ▸Phone-number login for delivery riders, email for diners and restaurant owners
- ▸Restaurant onboarding flow for owners to list a venue
- ▸Location selector and cuisine/restaurant search on the storefront
- ▸Cart state carried across the ordering flow
Want something like this?
Let's build your next product together.
Let's Talk