Build and Deploy a Restaurant Ordering System With Claude Code

Plan the Restaurant App

Open your project in Claude Code, fill in the three fields, and use this prompt. It only plans — nothing changes yet.

Plan the Restaurant Ordering System

Tell Claude what kind of restaurant this is and how customers will order, then let it plan the smallest useful ordering app before changing anything.

I want to build a real restaurant ordering web app with Claude Code. Restaurant type: {{RESTAURANT_TYPE}} Order mode: {{ORDER_MODE}} Menu direction: {{MENU_STRUCTURE}} Do NOT build anything yet. First inspect the existing project. If this is a new or empty project, inspect the current stack and configuration and plan the smallest appropriate implementation. Payment is handled by the restaurant outside the app (pay at pickup or at the counter). Do not plan online payments. 1. CUSTOMER WORKFLOW Plan: 1. Customer opens the menu 2. Browses categories 3. Adds items 4. Changes quantity or removes items 5. Reviews the cart 6. Provides only the order information actually required by the order mode 7. Places the order 8. Receives an order number / confirmation 9. Can see the simple current order status Do not require customer accounts. 2. RESTAURANT WORKFLOW Plan a proper protected Admin Dashboard. The restaurant owner and staff must NOT use the Supabase dashboard for normal daily operations. The Admin Dashboard should support: - staff / admin login - incoming order queue - order detail - changing order status - menu management - marking an item unavailable - editing menu item information Keep version 1 simple. 3. ORDER STATUSES Use the smallest useful status flow: NEW → PREPARING → READY → COMPLETED Include CANCELLED only if this restaurant's workflow genuinely needs it. Do not create a complex workflow engine. 4. DATA Plan the minimum data model. Likely concepts: menu category, menu item, order, order item, staff / admin access. Do not create unnecessary business entities. 5. SECURITY PUBLIC CUSTOMER may: - read available menu items - create their own new order through a safe path - retrieve only the minimum confirmation / status information for their own order PUBLIC CUSTOMER must NOT: - read all orders - edit order status - edit the menu or change prices - impersonate staff STAFF / ADMIN may: - sign in - read and manage orders - change status - manage the menu Being signed in is not the same as being restaurant staff — plan a trusted admin check. Never put a Supabase Secret / service-role key in browser code. 6. EXCLUDED FROM VERSION 1 Do not plan: online payments, delivery, customer accounts, loyalty or coupons, table reservations, POS or kitchen printers, multiple branches, inventory or ingredients, staff scheduling, analytics dashboards, email / SMS notifications. Return: RESTAURANT APP PLAN Customer pages: Admin pages: Order flow: Statuses: Data model: Authentication: Public permissions: Admin permissions: Menu management: Files / components likely needed: Features deliberately excluded: End with exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify anything yet.

What type of restaurant is this?

Coffee shop, burger restaurant, bakery, pizza takeaway...

How will customers receive their order?

What menu categories or items do you want?

Burgers, sides, drinks — or Coffee, pastries, sandwiches...

Review the plan before continuing. Version 1 should solve ordering and restaurant operations without becoming a full POS system.

Confirm the MVP

Make sure the approved plan includes exactly this:

Menu

Cart

Place order, paid at pickup or at the counter

Order status

Protected restaurant dashboard

Menu management

No unnecessary POS or ecommerce features

Create or Use the Supabase Project

If this project is already connected to the right Supabase project, reuse it — don't create a second one.

Open Supabase

https://supabase.link/r4gdwhi

Create a new project if you don't have one Open the project's Connect panel Copy the Project URL and the Publishable key Ask Claude Code which environment variable names this project uses, then add both values locally

IMPORTANT

The browser app only needs the Project URL and the Publishable key. Never put a Supabase Secret or service-role key in browser code or commit it to GitHub.

Create the Restaurant Database

Use this prompt in the same Claude Code session.

Create the Restaurant Database

Create the smallest Supabase structure for menu items, orders and restaurant staff with access rules that keep customer and admin actions separate.

Using the approved restaurant ordering plan, prepare the Supabase data model and access rules. Reuse correct existing tables where appropriate. Do not create duplicate data structures. Never print secret values. 1. MENU Create the smallest menu model needed, typically categories and menu_items. Menu item fields may include, only where useful: id, category, name, description, price, available, sort order, and an image URL if the design uses images. Do not add inventory quantities or ingredient management. 2. ORDERS Create the smallest order model, typically orders and order_items. An order includes only what is needed: order number / reference, status, order mode, customer name / contact where the order mode requires it, table number where required, an optional short note if approved, total, created time. Do not store unnecessary customer personal information. 3. ORDER ITEM SNAPSHOT Changing tomorrow's menu price must never change yesterday's order. Store on each order item: the menu item reference, the item name at order time, quantity, unit price at order time, and a line total if useful. 4. PRICE SECURITY — CRITICAL Do not trust prices or totals supplied by the browser. A customer must not be able to send price: 0.01 or an altered total and have it stored. Create orders through ONE trusted path — prefer a Postgres function called from the app (or a server route / Edge Function if the project's architecture already needs one) — that: - accepts only menu item ids, quantities and the order details - rejects unknown or unavailable items and invalid quantities - reads current prices from the menu - calculates the line totals and the order total - creates the order and its order items in one transaction, so a half-created order is never left behind - always starts the status at NEW - returns only the order reference, the status and a lookup token 5. PUBLIC CUSTOMER ACCESS Public customers may read the categories and available menu items needed for ordering, and create an order ONLY through the trusted path above. Do not give public customers direct table write permissions that let them choose prices, set status, change another order, or modify menu items or categories. 6. ADMIN ACCESS Create proper staff / admin authorization. Signed in is NOT the same as restaurant admin. Store admin status somewhere a signed-in user cannot change about themselves (for example a staff table that only trusted setup can write to), and check it in the database rules. Admins may read orders, change order status and manage the menu. Nobody may gain admin access by changing browser state, localStorage, profile data or request parameters. Tell me how to grant the FIRST admin safely (for example one reviewed SQL statement run once in the Supabase SQL Editor) — never through self-service sign-up. 7. ROW LEVEL SECURITY Enable Row Level Security on every table. Public menu reads expose only the data intended to be public. Administrative reads and writes require the trusted admin check. Do not use broad USING (true) for private or admin operations. Do not disable RLS to make the app work. 8. ORDER STATUS LOOKUP Customers check their status without an account. Do NOT expose an order just because its id is known. Use an unguessable lookup token and a narrow read path (for example a function that takes the token) that returns only what the customer needs, such as: Order #A104 — Preparing Never return other customers' information or the full order table. Give me: 1. Tables reused 2. Tables created 3. Order creation model 4. Price verification model 5. Public menu permissions 6. Customer order permissions 7. Admin authorization model 8. How to create the first admin 9. Order status lookup model 10. ONE reviewed SQL / migration block, including a few harmless demo menu items from the approved plan 11. Any server route or Edge Function required 12. Any blocker Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not execute destructive database work automatically, and do not build the UI yet.

Review the database plan and SQL, then apply it with your project's Supabase workflow — usually the SQL Editor in your Supabase project. Create your own staff account and grant it admin access the way the report describes.

The tables, access rules and demo menu items exist in Supabase

My staff account has admin access

Build the Menu and Cart

Build the Customer Ordering Experience

Build the public menu, cart and checkout-style order form using the existing design without adding online payments.

Build the customer-facing restaurant ordering flow from the approved plan, using the Supabase data model and trusted order path we just created. Use the existing project design and components. Do not redesign unrelated parts of the website. Do not add online payments — payment happens at pickup or at the counter. 1. MENU Show the real menu from Supabase, grouped by the approved categories. Each item shows only useful information: name, description, price, image if used, availability. Unavailable items are not orderable. Do not keep fake menu data in the UI once Supabase is connected. Handle loading, empty and error states. 2. CART Allow: add to cart, increase quantity, decrease quantity, remove, and view the total. Cart state may stay client-side — it is temporary UI state — but the database order pricing is authoritative. The browser total is a display value only. 3. ORDER DETAILS Collect only the fields the approved order mode requires. Pickup, for example: name, the minimum contact detail the restaurant needs, an optional short note if approved. Table order, for example: table number, optional name, optional short note. Do not collect an address — delivery is out of scope. 4. PLACE ORDER Connect Place Order to the trusted order-creation path only. Send menu item ids, quantities and the order details — never prices, totals, status or admin fields. The trusted path validates items, rejects unavailable items, uses current prices, calculates totals, creates the order and its items together, and starts the status at NEW. 5. DUPLICATE SUBMISSION Disable Place Order while the request is in progress, and add backend duplicate protection if the order path needs it. Do not rely on the UI for security. 6. SUCCESS After success: clear the cart, show the order confirmation with the order reference and current status, and give the customer the safe status link / lookup for their order. Do not display internal database details. 7. ERROR If order creation fails: keep the cart, show a useful generic message (for example when an item just became unavailable), and never show raw Supabase or database errors. Never show a fake success. Use the Supabase Project URL and Publishable key through the project's environment-variable pattern. No Secret / service-role key in browser code. When finished, report: - customer routes / components - menu source - cart implementation - order fields - trusted pricing path - duplicate protection - success and error behavior

Test a Customer Order

Run the app and place an order with test data:

Menu loads

Add two items

Change a quantity

Remove one item

Place a test order

Confirmation appears with an order reference

The stored total matches the menu prices

The new order starts with status New

Checking the stored order in Supabase is fine while you test. The restaurant itself will use the dashboard you build next.

Build Admin Login and Dashboard

Build the Restaurant Admin Dashboard

Create a protected restaurant dashboard for daily order and menu management without using Supabase as the operational interface.

Build the restaurant's protected Admin Dashboard using the approved Supabase admin authorization model. This dashboard is the restaurant's normal daily operational interface. Do NOT make the owner or staff edit rows in Supabase. 1. ADMIN LOGIN Use Supabase Auth for staff sign-in. If authentication already exists, reuse it. Otherwise implement the smallest secure staff login appropriate to this project (email and password is enough). Do not add customer accounts or public sign-up for staff. Do not add Google login unless the project already uses it. 2. ADMIN AUTHORIZATION After sign-in, verify the user is actually allowed to administer this restaurant. A signed-in user without admin access sees a clear "no access" state. Do not rely only on hidden navigation, localStorage, frontend role state or editable browser data. The database rules must enforce admin permissions. 3. DASHBOARD HOME Focus on what staff actually needs: counts or groups for NEW, PREPARING and READY, and the current order list, newest work first. No fake analytics charts. No revenue dashboards. Refresh the order list so new orders appear without staff reloading the whole app (a refresh button plus light automatic refresh, or Supabase Realtime if the project already uses it). 4. ORDER ROW / CARD Show enough to work quickly: order reference, created time, order mode, customer name or table, item count, total, current status. 5. ORDER DETAIL Staff can open an order and see: items, quantities, notes, customer / table details, total, status. Hide internal database fields. 6. STATUS ACTIONS Allow only sensible transitions: New → Preparing → Ready → Completed If Cancelled exists in the approved plan, keep it an explicit, confirmed action. Status is never free-text. The database must reject a status change from anyone who is not authorized staff. 7. MOBILE AND TABLET Staff may use a tablet or phone. Use large, clear status buttons and readable order cards. Keep the design professional and simple. Do not change the customer ordering flow. When finished, report: - admin routes - how sign-in and admin checks work - where admin permissions are enforced in the database - order list, detail and status behavior - how new orders appear

Then sign in with your staff account and check:

Your test order appears in the dashboard

Open the order and see its items

Move it New → Preparing → Ready → Completed

Add Menu Management

Add Menu Management

Let restaurant staff update menu items and availability from the Admin Dashboard without touching Supabase directly.

Add a Menu section inside the protected restaurant Admin Dashboard. Reuse the existing menu data model. Allow authorized staff to: - view categories and items - create an item, if included in the approved plan - edit item name - edit description - edit price - change category where appropriate - toggle Available / Unavailable Do not create inventory quantities, ingredient tracking, or variants / modifiers unless they were explicitly approved earlier. 1. PRICE EDITS Validate prices: no malformed, empty or negative values. Menu changes affect NEW orders only — past order item snapshots stay unchanged. 2. AVAILABILITY When staff marks an item unavailable, the customer menu shows it as unavailable. The trusted order-creation path must still reject that item even if a customer's browser has a stale cart. Do not rely on hidden or disabled UI. 3. SECURITY Only authorized restaurant staff can write menu data. A public visitor or a signed-in non-admin calling the same database mutation must be rejected by the database rules. Keep it usable on tablet and phone. Do not redesign the rest of the dashboard. When finished, report: - menu management screens - which fields are editable - price validation - how availability is enforced for new orders - where menu write permissions are enforced

Then check:

Edit an item's price from the dashboard

Mark a menu item unavailable

The customer can no longer order that item

Run the Full Customer-to-Kitchen Test

Open the customer menu in one window (ideally on your phone) and the Admin Dashboard in another.

Customer: open the menu, add an item and place a test order

Customer: keep the order reference or status page open

Admin: sign in, see the new order and open it

Admin: change New → Preparing

Customer: refresh the status and see Preparing

Admin: change Preparing → Ready

Customer: see Ready

Admin: mark the order Completed

Verify the Ordering System

Verify the Restaurant Ordering System

Verify customer ordering, trusted pricing, restaurant access and order status before deployment.

Perform a focused verification of this restaurant ordering system. Use test orders and test data only. Do not add features. Never print secret values. 1. PUBLIC MENU Verify: - available menu items can be read - unavailable items cannot be ordered - public users cannot edit menu data 2. ORDER CREATION Verify: - a customer can create a valid order - authoritative menu prices are used - browser-supplied fake prices or totals are ignored or rejected - unavailable item attempts are rejected - new orders start at NEW - duplicate or half-created orders are avoided 3. PUBLIC ORDER ACCESS Verify: - the status lookup exposes only the intended order reference and status - a customer cannot enumerate or read all restaurant orders - private customer details are not publicly readable 4. ADMIN Verify: - admin login works - a public visitor or a signed-in non-admin cannot open or change admin data - order status changes require authorized staff - menu writes require authorized staff 5. STATUS FLOW Verify NEW → PREPARING → READY → COMPLETED works, and the customer's status view follows it. 6. MENU MANAGEMENT Verify: - price changes affect future orders - old order item snapshots keep their original values - an unavailable item is rejected for new orders 7. SECRETS Confirm no Supabase Secret / service-role key or other private server credential exists in browser code. Return exactly one: ORDERING SYSTEM VERIFIED or: NEEDS ATTENTION If NEEDS ATTENTION, list only issues directly related to the restaurant ordering workflow. Do not perform a broad security or performance audit.

Run one final customer order and move it to Ready from the Admin Dashboard before deploying.

Put the App on GitHub and Hostinger

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No Supabase Secret or service-role key is in browser code

You know the production environment variable names

Push the project to GitHub with Claude Code or your normal GitHub workflow. If it already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the restaurant app's repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Add the Supabase Project URL and Publishable key under the names your project already uses. Private server keys stay private — never rename one to a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Test the Live Restaurant

First add your live Hostinger URL in Supabase so staff sign-in works in production:

Supabase Authentication URL Configuration

Set the Site URL to your live URL and add it to the Redirect URLs. Then open the live app and check:

Live menu loads

Cart works

Place a test order

Admin login works

The new order appears and its status changes

The customer status updates

A menu availability change works

Refreshing an important page still works

The menu works on a phone and the dashboard works on a tablet or phone

Verify the Live Restaurant Ordering App

Check the live Hostinger app from customer order to restaurant dashboard before using it with real customers.

Perform a focused production verification of this restaurant ordering app, now live on Hostinger. Do not add features. Never print secret values. Do not claim to inspect Hostinger or Supabase dashboard state you cannot access — ask me for the live URL and to confirm specific settings when needed. 1. GITHUB - the current approved source is present - no secrets or .env files are committed 2. HOSTINGER - the deployment succeeded - the correct repository and branch are connected - the framework / build configuration is correct - the required environment variables are configured 3. SUPABASE - the live app uses the intended Supabase project - no Secret / service-role key is exposed client-side - staff authentication works on the live URL - admin access is enforced 4. CUSTOMER FLOW - the menu loads - the cart works - a test order can be created - authoritative pricing remains correct - the order confirmation and status view work 5. RESTAURANT FLOW - staff can see the new order - status moves New → Preparing → Ready → Completed - a menu availability change works 6. CROSS-ACCESS - public users cannot edit the menu - public users cannot change order status - public users cannot retrieve all restaurant orders 7. RESPONSIVE - the customer menu is usable on mobile - the Admin Dashboard is usable on tablet and mobile Return exactly one: RESTAURANT APP LIVE or: NEEDS ATTENTION If RESTAURANT APP LIVE, summarize: live deployment result, customer ordering result, Admin Dashboard result, order status result, menu management result. If NEEDS ATTENTION, list only launch blockers.

Place one final test order on the live site and move it through the dashboard before giving the URL to the restaurant.