Ember · A Restaurant Site That Takes the Order Itself

A storefront for a fictional Houston West African fire kitchen, built around the question every restaurant owner eventually asks: can the website actually take the order?

Most restaurant sites are a menu PDF and a phone number. Every order that arrives through them costs something, either a staff member pulled off the floor mid-service or a marketplace app that takes a cut and owns the customer relationship afterwards. Ember answers with three working systems and a menu the owner edits themselves. Nothing here is a static mockup: you tap real dishes, pick real time slots, and watch a real order move.

The three systems

1. Live order builder. Tap dishes, filter by category, and a floating cart tracks the basket with live totals through to a full /cart page. There’s a card-payment demo modal for the checkout flow, and a one-tap hand-off, by WhatsApp or SMS, the guest’s choice, that arrives pre-filled with the whole basket, so the kitchen reads a clean ticket instead of decoding a back-and-forth chat.
2. Reservation widget. Choose the occasion and party size, pick from the next seven days (Mondays closed), and see time slots with realistic live availability. Confirm and you get a booking summary and a WhatsApp or SMS confirmation, with no phone call during service.
3. Delivery tracker. An animated, phone-style order tracker that auto-plays on scroll, Received → On the fire → Out for delivery → Delivered, alongside coverage zones with their fees and ETAs, so a customer knows what delivery costs before they order.

The menu admin

Behind a password at /admin sits an editor for the whole menu: add, edit, reorder, and delete dishes, upload a photo for each, set prices, categories, heat level, and tags, and toggle a dish on or off. Dish records live in Cloudflare D1 and photos in R2, with uploads compressed in the browser and capped at 2 MB.

Because the site is server-rendered from the database on every request, edits go live for every visitor, and are indexed by search engines, with no rebuild and no developer. When a dish sells out or a price moves, the owner changes it in ten seconds. The dishes checked into the repo are the seed for the table and the fallback if D1 is ever unreachable, so the menu is never empty.

Why this shape

Restaurants lose orders in the gaps: a menu that’s out of date, a booking that needs a phone call mid-service, a delivery question nobody answers. Each of those gaps either loses the order outright or quietly hands it to a platform that charges for the privilege. Ember closes every one of them on the page the customer is already on, then routes the confirmed order straight to the kitchen. No app to install, no account to create, no commission on the way through.

Stack

• Astro 7 + Tailwind 4, server-rendered on Cloudflare Pages
• Four routes: home, /menu, /cart, and the password-protected /admin
• Vanilla TypeScript for all three interactive systems, no React, no client framework
• Cloudflare D1 for the live menu and R2 for dish photos, behind API routes for menu CRUD, image upload, and auth
• The Last Trunks display face + Hanken Grotesk + JetBrains Mono for tickets and prices
• Warm cream, charred ink, ember red, saffron, and palm green, the bold, appetising language of a food brand, with a hand-drawn SVG icon set and a Restaurant schema.org for search

Why this matters

A site that only lists the menu makes the customer do the work, and makes the owner pay someone else to do it properly. Ember does the work on the restaurant’s own domain: it takes the order, holds the booking, and tracks the delivery, instead of ringing the phone mid-service or sending the customer through an app that keeps the relationship afterwards. That’s the difference between a brochure and a storefront.