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.

Refreshed again in September 2026: a warmer, more confident look built on the same structure, with the ordering, the phone and the directions pulled into the header on every page, WhatsApp back in the corner, the delivery platforms listed rather than hidden, and the accessibility standard stated in the footer. The structure did not need changing, which is the point of getting it right the first time.

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. Order, call, message or get directions from anywhere

   Ordering, the phone and directions sit in the header on every page, with WhatsApp in the corner. Most food decisions are made on a phone, standing up, and a number you have to memorise is a number nobody rings.

4. Every way people already order

   The order button goes to their own storefront, and DoorDash, Grubhub and Uber Eats are listed rather than fought with. People order where they already have an account.

5. Real food photography and their own reels

   The actual dishes, and video from the stall. People choose a food business by looking at the food, and stock imagery reads instantly as not-your-food.

6. Built to WCAG 2.2 AA, and it says so

   The footer states the standard and links an accessibility page. A restaurant site is read by people with poor eyesight in bad light more often than anyone plans for.

How it performs

• 672 msto paint the main content, on an emulated mid-range phone
• 212 msto first byte
• 795 KBtransferred, across 34 requests

Measured 2026-09-25. 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 2.1× 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.