Industries
Hours, menu, table. Three taps, on a phone.
Restaurants, cafés, bakeries, bars, food trucks and caterers. Almost every visit is someone standing on a pavement deciding where to eat in the next twenty minutes — and the site has one job for them.
What we hear
Decided in under a minute, on a phone
Nobody reads a restaurant website. They check four things and leave.
“Are you open right now?”
“Can I see the menu — the real one?”
“Can I book, and for how many?”
“Is there anything I can actually eat?”
“Do you deliver, or is it pickup only?”
What we build
Four things, done properly, in that order
Hours that are right in both places
On the site and on the Google listing — including the holiday ones people only check when it matters.
A menu as a web page
Readable on a phone, updatable by you in a minute, and legible to search. Not a PDF.
Booking that goes where you already work
Your reservation system, a form, or the phone. Whichever the front of house actually uses.
Allergens and dietary options, marked
Written once, next to the dishes, instead of relayed over a loud room.
Ordering and delivery, stated plainly
What you do yourself, what runs through a platform, and what you would rather people phoned about.
Photographs of the room and the food
The decision is partly about whether the place looks like somewhere to spend an evening.
Changes you make yourself, in a minute
A new menu, a holiday closure, a sold-out dish. If it needs a developer it does not get updated, and a wrong menu costs more than no menu.
What it's worth
What it's worth on a busy service
Four things a site does for a food business, most of them measured in interruptions that never happen.
Decided on the pavement, in under a minute
Open now, the real menu, allergens, delivery or pickup. Four answers, and the choice is made without a call.
Findable at the moment the decision happens
Maps, search and a listing that says exactly what the site says, for the person standing outside deciding where to eat.
The table booked without interrupting service
Reservations arriving through the system you already run, with the covers and the time attached.
Nothing wrong on the internet at six o'clock
A price, a special, a holiday closure: changed once by you and right in both places, instead of a job somebody has to remember twice.
A worked example
How we would approach a café with a PDF menu
Not a project we have run — a walk-through of the reasoning, so you can judge it before you hire anyone.
A café with good trade, a menu that changes every few weeks, and a website nobody has touched in two years. The menu is a PDF that opens sideways on a phone. Holiday hours are correct on the door, wrong on Google, and absent from the site. Staff take booking calls during service.
We would start with the menu, because it is the reason people open the site at all. It would become a web page you can edit yourself — change a price, pull a dish, add a special — and it would be readable on a phone without pinching.
Hours would live in one place and be published to both the site and the Google Business Profile, so the two cannot drift apart. Holiday hours would be part of that, not an afterthought in December.
Booking would connect to whatever system you already run, or become a short form if you run none. The aim is fewer calls during service, not a new tool for the staff to learn.
Allergens and dietary markers would sit against the dishes themselves, so the answer travels with the menu instead of being asked across a busy room.
Then we would stop. A café site that does those four things well beats a bigger one that does eight things adequately.
This is an illustration, not a case study. We have not yet built for a restaurant or café — the three projects on our work page are a clinic, a contractor and a studio. We would rather show you the reasoning than imply experience we do not have.
Services that fit
What food businesses usually start with
How it goes
Four steps, no surprises
A call, ideally not at service
What people phone to ask, what the front of house is tired of relaying, and how often the menu really changes.
Scope and a fixed price
Written down and agreed before anything gets built. The price does not move afterwards.
Built in stages
You see it in pieces and react as it goes up — not one reveal at the end.
Handed over in your name
Domain, hosting, profile, code. Every account is yours, and someone on your team is shown how to change the menu.
We use AI to move faster through the parts of a build that are the same every time. We review everything it writes, and we test for the vulnerabilities it introduces.
See the full processWhy Latchford
Four promises, in writing
Fixed price, agreed before we start
Written scope, so you know what you are getting
You own everything — code, domain, and accounts
We are here after launch, not just until it ships
Tell us what you're trying to get done.We'll tell you what it takes.