Build notes

Notes from building Meet My Menu.

Short, practical writing about accessible product decisions, honest menu data, and testing voice-first experiences.

How people find restaurants in the age of AI

Finding a restaurant is no longer one search. About one in five U.S. diners now uses AI to choose where to eat, and AI names a handful of places instead of listing them all. A restaurant that is not in that short answer is invisible.

The research: 22% have chosen a restaurant with AI, nearly half of real restaurants went unrecommended in a controlled audit, and voice assistants speak a single result. It also models what an AI-visible, machine-readable menu is worth in real revenue.

The business case for an accessible online menu

Most people decide whether to try an unfamiliar restaurant before they walk in, call, or reserve, and the piece of information they check most is the menu. This report gathers the evidence: 85% of diners read the menu online before choosing, an unreadable menu quietly loses customers, and an accessible, structured menu is what search engines and AI assistants can actually read.

It also covers the parts most pitches skip: the accessibility market and its legal exposure, the shift to voice and "near me" search, and the honest limits of the data.

Teaching a menu reader to say “I only found part of this”

A menu answer can sound complete even when its source is not. A restaurant page might show only lunch, a photo might cut off the bottom, or search results might contain an old menu.

For Meet My Menu, saying what was found is only half the job. The product also needs to say what may be missing. That gives the diner a chance to search again, scan another page, or ask restaurant staff.

Uncertainty is not a failure state to hide. Spoken clearly, it is useful information.

Why a green accessibility audit is not the finish line

Automated tools catch real problems: missing names, poor structure, and common contrast or keyboard issues. They cannot tell us whether spoken scanning guidance arrives at the right moment or whether a long menu is understandable through a screen reader.

A voice-first flow has to be tried as a voice-first flow. That means testing with the screen off, listening to the order of information, and checking whether recovery from a mistake is clear.

The audit is a gate. The lived interaction is the test.

The one-real-world-test standard

A feature can work perfectly with a clean sample menu and fail in a dim restaurant with a glossy, folded page. One real-world test often reveals more than another round of polishing the ideal case.

For a menu reader, that test should include a real menu, an actual phone, and the accessibility tools a diner uses. The goal is not to prove the feature works. It is to find the point where it stops helping.

That standard keeps product decisions tied to the experience the app is supposed to improve.