Websites
A website for your restaurant
A site a hungry person can open on their phone, find your menu and hours in seconds, and tap straight through to order or reserve.
Someone is deciding where to eat tonight. They are on their phone, they are hungry, and they have your name. They want three things in the next ten seconds: your menu, your hours, and a way to act. If your site makes any of those hard to find, they have already opened a competitor's.
Most restaurant websites fail at exactly this. The menu is a blurry PDF that pinches and zooms on a phone. The hours are buried or wrong. The site is slow, the photos are stock, and the order button links somewhere that no longer exists. We build the opposite: a site that respects how people actually look up a place to eat.
The menu is the website
For a restaurant, the menu is not a page on the site. It is the reason the site exists. Get it right and most of the job is done.
That means your menu lives as real text on your own pages, not a PDF and not stranded on some platform you stopped paying for. A PDF is slow to load, awkward to read on a phone, and Google cannot see what is in it. Real text loads instantly, reads cleanly on any screen, and shows up in search. When you change a price, drop a dish, or add a special, you change it in one place and it is current everywhere that day.
Owning the menu on your own site matters more than it sounds. Restaurants get locked into builder platforms and directory listings, then find they cannot edit their own menu without paying, or that it vanishes when the subscription lapses. Your menu should never depend on someone else's account staying open.
Built for the phone, because that is where people look
The person checking your restaurant is rarely at a desk. They are walking, on a bus, or already standing near your block deciding whether to come in. So the site is built for the phone first, not shrunk down from a desktop layout as an afterthought.
That has real consequences for how we build. Pages stay light so they load on a weak signal. Tap targets are big enough to hit while walking. Hours and location sit near the top, not three scrolls down. And we test it on actual phones, not just a browser window pretending to be one.
Speed is part of this. A site that takes five seconds to load loses people before they ever see the food. We keep the code lean and the images sized correctly so the page is usable almost immediately.
Show the food, and make it easy to act
People eat with their eyes first. Real photos of your actual dishes do more than any description, so we build around good food photography rather than generic stock images. If you do not have photos yet, we will tell you that getting them is worth doing before launch.
Then we make it easy to act on that hunger:
- Order takeout. A clear button that links straight out to the ordering service you already use.
- Buy a gift card. Routed to your existing gift system, working the same way.
- Find you. Address, map, and hours that are correct and obvious.
- Call or reserve. A tappable phone number, and a link to your reservation tool if you take bookings.
We connect to the tools you already run. We do not rebuild ordering or payments from scratch, because that would cost you more, add fees, and serve diners worse than the services built for it.
Show up when people search for your food
When someone searches for your kind of food near them, you want to be in that result. A lot of that is structure the visitor never sees: your hours, address, and menu marked up so Google reads them correctly, fast pages, and clean links. We build that in from the start, and we make sure your site lines up with your Google listing so the two agree on the basics.
This is not a magic ranking trick, and we will not promise you the top spot. It is doing the plain work properly so search engines can understand who you are and what you serve.
Keep it simple, do not overbuild
Many restaurants do not need a big site. They need one page that loads fast, shows the menu, makes the hours and location obvious, and links out to order and buy gift cards. That is often the right answer, and it is cheaper to build and run. We would rather ship you that than sell you a sprawling site you will never update. When more pages genuinely help, we will say so, and when they would not, we will say that too.
How we work
We build a working prototype of your site before you pay for the full thing. You see your real menu, your photos, and the actual buttons on a real screen, and you decide from there. We already did this for The Griffon, a local pub: a homepage prototype that hosts the full menu on the page itself and links straight out to online ordering and gift cards, exactly the pattern above.
We are a principal-led practice, so the person who plans your site is the person accountable for it shipping. We price the real build as a fixed scope, and we leave you owning the code and the content outright. You can update it, move it, or hand it to anyone, with nothing held back.
- Can you just use our menu PDF?
- We would rather not. A PDF is hard to read on a phone, slow to load, and invisible to Google. We rebuild your menu as real text on the page, which is faster for diners and lets you change a price without re-exporting a file. It is more work up front and worth it.
- Do you handle the online ordering itself?
- No, and that is on purpose. If you already use an ordering or gift-card service, we link straight out to it so you keep your accounts, your fees, and your data. Building a payment system from scratch would cost you more and serve you worse. We connect what you have.
- We are a small place. Do we need more than one page?
- Often not. A single, well-built homepage with your menu, hours, location, and the right buttons is enough for many restaurants, and it is cheaper to run. We scope to what you actually need and tell you when more pages would be wasted money.
- Who owns the site and the photos?
- You do. The code is yours, the content is yours, and you can move it or hand it to another developer whenever you like. No lock-in, and nothing held hostage if you ever leave.