Two weeks. Three devs. A premium UI food-delivery demo ready.
This is the build plan for the Primotech Food Delivery MVP, covering three demo apps: Customer, Rider, and Admin Web. To meet the two-week timeline, we are strictly building a UI-only experience. There is no backend. Instead, we'll use hardcoded JSON and scripted timing to make the order flow feel completely real during a live demo. A team of three frontend developers will build and link every screen in week one, and dedicate week two entirely to premium polish and deployment.
01The three demo apps we're building
One food-delivery MVP, three surfaces. We will share the live URL of the admin web and the app links for the customer and delivery partner. Each app is UI-complete and navigable, runs on hardcoded demo data, and scripts a happy-path flow that looks indistinguishable from the real thing in a short live demo.
For customers, to discover restaurants, build a cart, place an order, and watch the rider live on a map.
For delivery riders, to see nearby orders, accept one, navigate pickup → drop, and mark delivered.
For restaurant staff, the main moment: when an order comes in, the screen shows a bold NEW ORDER banner + sound. Accept, assign a rider, done.
~33 screens total. Restaurant-side accept order lives inside the Admin web. No separate Merchant app.
02Skipping the backend to focus on UI
To make sure the user experience is absolutely top-tier, we're intentionally leaving out the backend for this MVP. That means no servers, databases, or live auth providers to slow us down. Instead, everything runs smoothly on hardcoded JSON data and local state. We'll use cleverly timed scripts to simulate the real-time magic of an order moving from the Customer, to the Admin, to the Rider. It'll look perfect on video and feel incredibly real during a live demo.
Food images pulled from the open web (Unsplash, Pexels, whatever looks right) so every restaurant and dish has an image, no empty grey placeholders. Skeleton loaders, not spinners. Smooth screen transitions and micro-animations on cart updates. Haptic feedback on key actions. Proper empty states. Pull-to-refresh that feels native. Typography and spacing that look designed, not defaulted. Pixel-checked on a real device every day. This is the work.
How works like a real app happens without a backend
- Data: hardcoded JSON (10 restaurants, 50 menu items, 30 historical orders, 5 riders, 1 demo user).
- Auth: phone-OTP screens are UI only. Any number + code
000000logs in to the hardcoded demo user. No SMS, no provider. - Order placement: writes to local state (AsyncStorage on mobile, localStorage on web).
- Cross-app feel: since real-time communication isn't possible without a backend, we will record demo videos in a way that makes the apps feel like they are communicating live. We simulate real-world pacing with intentional delays—a scripted timer in the Admin web shows NEW ORDER ~3s after a customer order, and the Rider app surfaces it ~5s later.
- Live tracking: the rider icon animates along a pre-defined map route, no real GPS, no realtime layer.
- Push notifications: in-app toast/banner only. No real OS push (no FCM, no APNs registration).
03A breakdown of every screen we'll build
Each screen is sized to fit one focused day of work or less. The basics (profile, notifications, order history, addresses) are explicitly in, a demo without them looks like a prototype, not a product.
Customer app,12 screens
| # | Screen | What it does |
|---|---|---|
| 1 | Splash / Onboarding | Brand splash, two-slide intro for first-time users. |
| 2 | Phone, enter number | Country code + number input (UI only, no SMS sent). |
| 3 | Phone, enter OTP | 6-digit input. Universal demo code 000000 always works. |
| 4 | Home | Location bar, search shortcut, categories carousel, near you restaurant feed. |
| 5 | Search | Full-screen search across restaurants and dishes, recent searches, filter chips. |
| 6 | Restaurant detail | Banner image, rating, delivery time, menu grouped by category. |
| 7 | Item detail | Photo, description, customization options, qty stepper, add-to-cart. |
| 8 | Cart | Line items, qty edit, subtotal + fees breakdown, proceed to checkout. |
| 9 | Checkout | Delivery address picker, fake payment method tile, place-order button. |
| 10 | Order tracking | Status timeline + animated rider on a Google Map (scripted route). |
| 11 | Order history | List of past orders (hardcoded) with reorder button. |
| 12 | Profile | Name, saved addresses, payment methods, notifications toggle, logout. |
Rider app,12 screens
| # | Screen | What it does |
|---|---|---|
| 1 | Splash / Onboarding | Brand splash + two-slide intro (earn on your schedule) for first-time riders. |
| 2 | Phone, enter number | Country code + number input (UI only, no SMS sent). |
| 3 | Phone, enter OTP | 6-digit input. Universal demo code 000000 always works. |
| 4 | Home / dashboard | Online/offline toggle, today's earnings summary, current shift status, quick nav. |
| 5 | Available orders | Scripted list of unassigned orders nearby with payout, distance, tap to view. |
| 6 | Order detail (pre-accept) | Pickup + drop addresses, distance, payout breakdown, accept / decline. |
| 7 | Active delivery | Map + step actions (arrived at pickup, picked up, arrived at drop, delivered). |
| 8 | Delivery summary | Post-delivery recap, tip prompt, earnings added, next-order CTA. |
| 9 | Earnings / history | Today/this-week earnings + past deliveries list (hardcoded). |
| 10 | Notifications | Delivery alerts, payout updates, system messages (mock list). |
| 11 | Profile | Name, bike info, mock-KYC status, ratings summary, logout. |
| 12 | Settings / Help | Notification toggles, language, in-app FAQ + contact-support form. |
Admin web,9 screens
| # | Screen | What it does |
|---|---|---|
| 1 | Login | Email + password (any input passes; internal-only surface). |
| 2 | Dashboard | KPI cards (orders today, revenue, active riders) + orders-over-time chart. |
| 3 | Orders, list | Filterable table. The main moment: when a new order arrives, top of screen flashes a bold NEW ORDER! banner with sound. |
| 4 | Order detail | Customer + restaurant + items. Accept / reject / assign-rider actions, the merchant accept lives here. |
| 5 | Restaurants, list | Searchable table with add / edit / disable. |
| 6 | Restaurant menu mgmt | Categories & items CRUD; price, image, availability toggle. |
| 7 | Riders, list | Active riders, current status (free / on-delivery), add new rider. |
| 8 | Customers, list | Read-only customer list with order count + last order date. |
| 9 | Settings | Admin profile, app-wide toggles, notification preferences. |
04How we build: clear specs & AI assistance
We like to be very intentional before we write a single line of code. By writing out clear, simple requirements in Markdown first, we can guide our AI coding tools to generate exactly what we need, keeping us moving fast and staying on track.
For example, before building the Customer Home screen, we write a strict 03-home.md spec detailing:
05Where we're finding our UI inspiration
To maintain velocity, we leverage high-quality open source Figma community templates for our design foundation rather than designing from scratch. We can pull screens, components, and layout ideas directly from these UI kits:
- Swiggy Full UI Kit
- Food Delivery App Kit 1
- Figma Community Search: Food Delivery
- Food Delivery App Kit 2
Extract the design tokens (colors, typography, spacing) and use them to guide the AI prompt when generating components.
06The team breakdown: who's building what
We have three developers, and each person gets to fully own one of the apps. Since there's no backend and no shared components to wait on, everyone can dive straight into building UI from Day 1 without blocking each other. We'll check in daily to celebrate what we've shipped and help each other out.
Owns the Customer app end-to-end. This is the app that drives the demo video, the home, the cart, the checkout, the live order-tracking moment. UI is built inside the app, not shared across apps.
Screens owned (12)
- Splash · Phone-OTP (number + code) · Home · Search
- Restaurant detail · Item detail · Cart · Checkout
- Order tracking (with animated map) · Order history · Profile · Notifications
Week 1 deliverables
- Customer app skeleton + nav + own theme tokens / component set.
- Phone-OTP UI flow wired (any number +
000000→ demo user). - Own demo-data JSON (restaurants, menu items, orders for this app).
- Home, search, restaurant detail, item detail, cart, checkout.
- Order tracking screen with status timeline (animated map is Week 2).
Week 2 deliverables
- Animated rider on Google Map (scripted route).
- Order history, Profile, Notifications screens.
- Premium polish: empty/loading states, micro-animations, haptics, web-sourced food images.
Depends on: nothing, can start Day 1 morning.
Owns the Rider app end-to-end. No backend work. Free to spend the entire two weeks making the Rider experience feel premium, map transitions, swipe-to-confirm actions, haptics on key steps.
Screens owned (12)
- Splash / Onboarding · Phone-OTP (number + code) · Home / dashboard
- Available orders · Order detail (pre-accept) · Active delivery (map + step actions)
- Delivery summary · Earnings / history · Notifications · Profile · Settings / Help
Week 1 deliverables
- Rider app skeleton + nav + own theme tokens / component set.
- Phone-OTP UI flow.
- Own demo-data JSON (rider profile, available orders, past deliveries).
- Home / dashboard, Available orders list, Order detail (pre-accept).
- Active-delivery screen with step actions (mark picked up, mark delivered) and basic map.
Week 2 deliverables
- Scripted rider-location animation along a pre-defined route.
- Delivery summary, Earnings/history, Notifications, Profile, Settings/Help.
- Premium polish: swipe-to-confirm, transition animations, haptic feedback.
Depends on: nothing, fully independent app, can start Day 1 morning.
Owns the Admin web. The headline interaction is the NEW ORDER alert, when a customer places an order in demo mode, the Admin orders screen flashes a bold banner with a sound. That is the screenshot we put on the website.
Screens owned (9)
- Login · Dashboard · Orders list (with NEW ORDER alert) · Order detail (accept + assign rider)
- Restaurants list · Restaurant menu management
- Riders list · Customers list · Settings
Week 1 deliverables
- App shell (Vite + Tailwind), sidebar nav, login (any creds pass), protected routes.
- Orders list backed by own demo data + filters by status.
- Order detail with accept / reject / assign-rider actions.
- Restaurants list + menu management (categories & items CRUD against local state).
Week 2 deliverables
- NEW ORDER alert: banner + sound when scripted timer fires (or when local state mutates).
- Dashboard charts (orders/day, revenue trend, top restaurants, active rider count).
- Riders list, Customers list, Settings.
- Final demo data polished (real-looking restaurant names, web-sourced food images, sensible prices).
- Deploy to Vercel; share preview URL with leadership and marketing.
Depends on: nothing, fully independent app.
07Week 1: Getting every screen up and running
- Dev 1: Bootstrap Customer Expo app, own theme tokens / component set, Phone-OTP UI flow, own demo-data JSON.
- Dev 2: Bootstrap Rider Expo app, own theme tokens / component set, Phone-OTP UI flow, own demo-data JSON.
- Dev 3: Bootstrap Admin web (Vite + Tailwind), shell + sidebar, login screen, own demo-data JSON.
- EOD: three independent repos pushed, each app renders its home screen on its own mock data.
- Dev 1: Customer Home, restaurant list, restaurant detail with menu, item detail.
- Dev 2: Rider available-orders list + order detail (pre-accept).
- Dev 3: Admin orders list with status filters + restaurants list CRUD.
- Dev 1: Cart, checkout (fake payment), order confirmation, order status timeline.
- Dev 2: Rider accept flow, active delivery shell (map + step actions).
- Dev 3: Admin order detail, accept / reject / assign rider. Restaurant menu mgmt CRUD.
- All three devs together: walk a scripted order Customer → Admin (accept) → Rider (deliver) on three devices in one room. Fix every visual break.
- Dev 1: Search screen.
- Dev 3: Riders list + add-rider form.
- Bug bash + visual cleanup pass.
- Final demo data: realistic restaurant names, web-sourced food images, sensible prices.
- Internal walkthrough with leadership on a real phone. Note every gap.
Every screen exists across all three apps. A scripted demo order flows Customer → Admin → Rider on local data. Week 2 is entirely about making it feel premium.
08Week 2: Animations, polish, and final delivery
- Dev 1 + Dev 2: Secondary screens (Notifications, Profile, Settings) + code cleanup.
- Dev 3: Admin Settings screen + Customers list.
- Dev 3: NEW ORDER banner + sound + flash animation in Admin orders list when scripted timer fires.
- Dev 1: In-app toast notifications in Customer on status changes (accepted → ready → picked-up → delivered).
- Dev 2: In-app toast in Rider on new-order-available.
- No real OS push (no FCM). Purely in-app, scripted by local timer.
- Dev 1: Customer order screen shows a rider icon animating along a pre-defined Google Maps route.
- Dev 2: Same scripted animation in Rider active-delivery screen.
- Dev 3: Dashboard charts (orders/day, revenue trend, top restaurants).
- Dev 1: Order history + Profile + Notifications screens.
- Empty states, loading skeletons, micro-animations on every list and card.
- Haptic feedback on key actions (add-to-cart, place-order, mark-delivered).
- Food images pulled from the open web (Unsplash, Pexels, etc.) so every restaurant and dish has an image.
- Deploy: Admin to Vercel, mobile apps to Expo EAS preview (shareable QR codes).
- Hand off EAS QR codes + Vercel URL to marketing.
- Walkthrough with the entire team. Shipped
Phone-OTP login is UI only. Any number + universal code 000000 logs in
to the hardcoded demo user. No SMS, no auth provider, no real account state. When/if a real client picks
this up, plugging in a real auth provider is a separate engagement, not in scope here.
09Our AI tooling strategy
Each developer gets one Cursor Pro subscription.
Rate-limit window. Cursor Pro has a 5-hour rolling reset window. The window starts on the first request and resets five hours later. Inside that window each dev gets a bounded number of premium-model requests (and unlimited Auto-mode requests after the premium budget is spent).
Managing limits. AI tools are incredible, but they do have usage caps. If we hit our request limits, we might experience a temporary pause. When that happens, we'll simply shift our focus to manual polishing, reviewing each other's work, or taking a well-deserved coffee break while our limits reset. We're planning for this so it won't derail us!
10The tech stack we're using
| Layer | Choice | Why |
|---|---|---|
| Mobile apps | React Native (Expo) | One codebase per app, fastest hot reload, AI generates Expo cleanly. |
| Admin web | React + Vite + Tailwind | Team already knows it. Vite dev server is fast. |
| Backend | None. | Demo apps. Hardcoded JSON + local state (AsyncStorage / localStorage). |
| Auth | UI only, demo code 000000 | No SMS, no provider. Login screens are pure UI. |
| Realtime | Scripted local timers | Cross-app flow simulated by scheduled state mutations in demo mode. |
| Notifications | In-app toast / banner only | No FCM, no APNs. The Admin NEW ORDER alert is local-state-driven. |
| Live tracking | Google Maps SDK + scripted route animation | Rider icon animates along a pre-defined path. No GPS. |
| Payments | Fake checkout UI | No real provider; place-order writes to local state. |
| AI tools | Claude Pro / Cursor Pro (1 per dev, $20) | Entry tier. See §08 for window limits. |
| Hosting | Vercel (web) + Expo EAS preview (mobile) | Shareable links and QR codes for sales calls in minutes. |
11Project scope: What's in and what's out
In scope
- Three demo apps: Customer + Rider (Expo), Admin web (React + Vite). ~33 screens total.
- Hardcoded demo data + scripted cross-app flow in demo mode.
- Phone-OTP UI (demo code
000000), in-app notifications, animated live-tracking map. - NEW ORDER alert moment in Admin (banner + sound + flash).
- Premium UI polish, the whole point of the build.
- Deployed preview links + QR codes for the marketing website.
Out of scope (explicitly not building)
- Any backend, no server, no database, no Firebase, no Supabase.
- Real authentication, real SMS, real payments, real push notifications.
- Separate Merchant app, restaurant-accept lives in Admin.
- App-store / Play-store submissions.
- Multi-tenant infrastructure, load testing, security review, production hardening.
- Ratings, promo codes, referrals.