Case study · Restaurant / Food

A restaurant site where the menu is the homepage

Building for the three questions every hungry visitor actually arrives with — and refusing to build a checkout nobody asked for.

Open the live build Website Development

Spice Route

Restaurant / Food · 5–8 days · ₹12,000–₹25,000

Go and use the build

The menu is page content, not an attachment

The whole menu lives in one structured object in the build — dish, description, price, and a veg/non-veg flag — and the page renders from it.

The veg marker is part of the data model, not a decoration

In India this is not a visual flourish — it is the first thing a large share of diners filter on, and getting it wrong is a serious error, not a cosmetic one.

The situation

What goes wrong here

Somebody looking up a restaurant on their phone has three questions, and only three: what do you serve, are you open, and how do I get it. Almost every restaurant website answers a fourth question first — our story, since 1998 — and buries the menu behind a nav link or, worse, behind a PDF that opens in a separate viewer and pinches to nothing on a phone.

The PDF menu is the single most expensive mistake in this category. It cannot be read comfortably on the device most people use, it cannot be indexed as page content, and it can only be updated by whoever owns the design file — so prices go stale and the owner stops trusting the site.

The second mistake is more subtle: building a full ordering system. A restaurant doing twenty orders a day is quoted a cart, a payment gateway and an order-status backend, and ends up paying for infrastructure whose running costs outweigh the margin on the orders it processes.

The decisions

Every one of these had a cost

A decision with no trade-off is a feature list. Each of these names what was given up, because that is the part a client needs to agree with before the project starts — not after.

01
The menu is page content, not an attachment
The whole menu lives in one structured object in the build — dish, description, price, and a veg/non-veg flag — and the page renders from it. That makes it real text: readable at any size, selectable, and indexable, so a search for a dish name can actually land on the restaurant. It also means changing a price is editing one line, not reopening a design file.
What it cost
Menu changes go through whoever maintains the site rather than being self-service. For a menu that changes seasonally that is fine; a restaurant changing prices weekly should be quoted a small admin panel instead, and told so before the project starts.
02
The veg marker is part of the data model, not a decoration
In India this is not a visual flourish — it is the first thing a large share of diners filter on, and getting it wrong is a serious error, not a cosmetic one. So it is a required field on every dish rather than an icon someone remembers to place, which means a dish physically cannot be added without answering the question.
What it cost
Slightly more rigid content entry. Worth it: the alternative failure mode is a mislabelled dish, which is the kind of mistake that ends a customer relationship permanently.
03
Ordering goes to WhatsApp instead of a cart
The order button opens a WhatsApp conversation with the restaurant. No account, no card entry, no abandoned-cart funnel — and the customer is already in the app they use all day. For the restaurant there is no gateway fee on each order, no payment data to secure, and no separate dashboard to learn: orders arrive where staff already look.
What it cost
No automated order tracking, no online payment capture, and no sales reporting — those need the ecommerce build, which starts at roughly twice the price. This is the right call at twenty orders a day and the wrong one at two hundred, and the honest version of this conversation happens before the quote, not after.
04
Table booking is a structured request, not a live calendar
The booking form collects date, time and party size and sends it as a message a human confirms. A real-time reservation system needs live table state, which needs someone maintaining that state all evening — a job restaurants of this size do not have staff for, and an unmaintained calendar is worse than no calendar.
What it cost
The diner does not get instant confirmation. In exchange the restaurant never double-books, never shows availability it cannot honour, and never has to keep a system in sync during a dinner rush.

In the build

Menu with category filtering, rendered from structured data
Photo gallery
Table booking request form
WhatsApp order button
Google Maps embed and directions
Opening hours and contact
Mobile-first throughout — this category is overwhelmingly phone traffic

Built with

Next.js
Tailwind CSS
WhatsApp deep links
Google Maps Embed API

You provide

Menu items, descriptions and prices
Food and interior photos
Logo, if one exists
Address, contact number and opening hours

Nothing starts until the scope, timeline and price are agreed in writing.

Measured

How this build actually performs

Taken from the finished build under throttled conditions, not from a score card. All six concept builds share a foundation, so they share these numbers.

Chromium at 412×915, 4× CPU throttling, 1.6 Mbps with 150 ms latency, cold cache — a mid-range Android phone on a typical Indian mobile network, not a developer's laptop. Includes the analytics the live site loads. Measured 2026-09-08.

Largest contentful paint: 1.58–2.16s; When the main content is actually on screen. Google treats anything under 2.5s as good.
Cumulative layout shift: 0; Nothing moves after it appears — no mis-taps caused by a button jumping.
JavaScript over the wire: 429 kB; Compressed, as actually sent — 259 kB of site code plus 170 kB of Google Analytics.
Total page weight: ~613 kB; Everything: markup, styles, fonts, scripts and analytics.

Honestly

What this is and isn’t

This is a concept build, not client work — the restaurant, its reviews and its photographs are invented so the build could be shown publicly without needing anyone's permission. What is not invented is the build itself: it runs, you can use it, and it is the same architecture a real project of this type would ship on.