Paanwalla

What it had to do

Two audiences on one site. Walk-in customers wanting to know what is on and whether it is open, and event organisers booking catering weeks ahead. The old build served the first badly and the second not at all.

What we decided

The menu was the whole problem. It had been a download, which is the single most common and most damaging thing a food business does to its own website: unreadable on a phone without pinching, impossible to enlarge for anybody with poor eyesight, and invisible to a search engine, so the business never appeared for a dish it was known for.

The second problem was that catering was buried. Event work is worth many times a walk-in order and arrives through a completely different search, weeks earlier, from somebody comparing three suppliers. It needed its own route through the site rather than a line on a contact page.

So the menu became a page a phone can read, catering got its own path with a booking form at the end of it, and the food got a section of its own. The measurements of the old build against this one are published in full, because the numbers were the argument.

What is on the site

1. A menu that is a page, not a download

   Readable on a phone without pinching, enlargeable, and legible to a search engine, so dishes can be found by name.

2. Catering as its own journey

   A separate route through the site ending in a booking form, because event enquiries arrive earlier and compare harder than walk-in trade.

3. Tappable phone and WhatsApp

   Both present on every page. Most food decisions are made on a phone, and a number you have to memorise is a number nobody rings.

4. Real food photography and video

   Four videos and the actual dishes. People choose a food business by looking at the food, and stock imagery reads instantly as not-your-food.

5. Online ordering in the header

   One tap from anywhere on the site rather than hidden behind a menu.

How it performs

• 352 msto paint the main content, on an emulated mid-range phone
• 107 msto first byte
• 1035 KBtransferred, across 39 requests

Measured 2026-09-20. Median of 3 loads, emulated mid-range phone at 390px, cold cache, waiting for the load event. For context, the median across the 300 Chicago-area small business sites we tested was 1,406 ms, and Google treats anything under 2,500 ms as good. This site is about 4.0× quicker than the local median.

Re-measured rather than remembered, which is why the date is on it.

Worth taking from this

The most valuable change was not the design. It was turning the menu from a file into a page, which took the site from invisible to findable for every dish on it.