Openfront Restaurant
Menu, ordering, POS, service floor, kitchen, inventory, staff, and reporting.
Openfront Restaurant is the restaurant branch of Openfront. It is not just the ecommerce build with menu labels swapped in. The current codebase covers the core restaurant loop: publish a menu, take orders from the storefront or staff-facing tools, route them into the kitchen, manage the floor, close the check, and report on the shift afterward.
Before using real service or payment data, verify payment handling, cart ownership, API-key enforcement, concurrency controls, build checks, and the deployed order flow.
What ships today
Storefront ordering
One-page ordering flow with menu browsing, cart, checkout modal, account pages, and order confirmation.
Point of sale
Fast dine-in and takeout order entry with table selection, courses, urgency, and payment handoff.
Service floor
Live table-service workspace for moving tables, splitting checks, firing courses, and closing checks.
Kitchen display system
Station-based ticket routing, all-day view, item-level completion, and expediter gating.
Menu and modifiers
Categories, items, images, allergen data, dietary flags, modifiers, featured items, and availability.
Inventory and recipes
Ingredients, vendors, purchase orders, waste logs, recipe costing, and stock depletion on completed orders.
Staff and labor
Staff records, weekly scheduling, tip pools, time-entry driven labor reporting, and compensation fields.
Reporting
Operational dashboard plus sales, menu performance, and labor views.
How the order lifecycle works
A guest or staff member starts the order
A guest can order through the storefront. Staff can start the same order from the POS or service-floor tools. In every case, the system writes a RestaurantOrder with structured OrderItem records underneath it.
Payment gets attached to the order
The storefront creates the order first, then creates a payment record and confirms it. In staff workflows, payments are usually handled at the end of service through the payment screen.
The order enters the kitchen pipeline
Once the order is paid or pushed forward, kitchen tickets are generated per station. Grill items go to Grill, fryer items go to Fryer, expo gets the final coordination view, and so on.
Front of house keeps the floor moving
Hosts work the waitlist and seating flow. Servers use the service-floor UI to add items, fire or recall courses, split checks, combine tables, and transfer active checks when service changes hands.
The shift closes with reporting and inventory updates
When an order reaches completed, recipe-linked ingredients can be depleted automatically, payments are recorded, and the reporting views pick up the finished sale.
The main product surfaces
Storefront
The storefront is a customer-facing menu and ordering experience. It is driven by StoreSettings, MenuCategory, MenuItem, MenuItemModifier, Cart, and CartItem. Guests browse the menu, customize items, choose pickup or delivery, and check out without leaving the page.
POS
The POS screen is built for opening orders quickly. Staff can switch between dine-in and takeout, select one or more tables, build a cart, assign courses, flag the order as urgent, and send it into service.
Service floor
The service-floor screen is where the restaurant starts to feel like restaurant software instead of generic admin UI. It tracks table states, lets staff open a table, add items to an active check, move parties, combine tables, split payments, and handle course timing.
KDS
The kitchen display system organizes tickets by station and by status. It supports ticket view, all-day view, overdue timing thresholds, item-level completion, and an expediter gate so expo cannot bump a ticket while prep stations are still working it.
Platform admin
The dashboard covers menu setup, store settings, payment providers, gift cards, discounts, onboarding, reports, staffing, and inventory workflows.
Current shape of the platform
Current implementation
- Storefront menu, cart, checkout modal, account area, and order confirmation flow
- POS order entry with tables, courses, urgency, and special instructions
- Service-floor actions for transfer, combine, split, fire, recall, and payment handoff
- KDS with station tabs, lane filters, all-day view, and item-level readiness tracking
- Menu modeling with images, featured items, modifiers, dietary flags, and meal-period tagging
- Store settings for hours, locale, currency, delivery fees, pickup discounts, and storefront copy
- Inventory, recipe costing, purchase orders, waste logs, and stock movements
- Staff scheduling, tip pools, and labor reporting driven by time entries
- Synthetic onboarding data for local evaluation and MCP assistant source, subject to the family security gates
Current boundaries
StoreSettings is a singleton. Although Organization, RestaurantGroup, and Location models exist, current orders, menu, inventory, floor, payment, and staff aggregates are not comprehensively partitioned by those records. Document and deploy this as one restaurant/one operating location unless the owning source adds and tests direct ownership across every aggregate.
- Stripe, PayPal, and manual adapters exist, but provider behavior is not uniform across every restaurant workflow. Verify the selected adapter's session, capture, refund, webhook, replay, and reconciliation path.
- Gift-card redemption has controlled POS behavior. Discount models and administration exist, but source does not establish automatic application across every order path.
- Reservation and waitlist models and commands exist; neither implies SMS delivery or a complete host-stand/provider workflow.
- Current source does not establish offline POS/device/printer guarantees, a durable check/tab and cash-ledger model, loyalty/CRM, delivery-marketplace dispatch, accounting/payroll export, or multi-location tenancy.
- Role, API-key scope, ownership, split-check allocation, and concurrent inventory/payment behavior require release-specific negative and runtime tests.
Stack and architecture
- Next.js 16 with the App Router
- React 19
- KeystoneJS 6 for lists, auth, and GraphQL
- PostgreSQL through Prisma
- Stripe, PayPal, and manual payment adapters
- Tailwind CSS and shadcn/ui for the interface layer
- MCP-backed AI actions in the dashboard
Openfront Restaurant keeps the same overall pattern as the original Openfront project: thin app routes, business logic in features/platform/* and features/keystone/*, and a GraphQL API as the shared contract across storefront, admin, and AI workflows.
Where to go next
Get it running
Install the app, create your first admin user, and seed a working demo restaurant.
Learn the storefront
See how guest ordering, checkout, and order confirmation work.
Run the floor
Use the table-service workspace for live dining-room operations.
Configure payments
Understand the Stripe, PayPal, and manual adapter setup.