I built the website for Walrus Subs, a sub shop in Austintown, Ohio, and I've kept it running since September 2024. The business reports online orders up 35% after the new site replaced their old one.
Context
Walrus Subs competes the way every local restaurant competes now: someone gets hungry, pulls out a phone, and searches. Whoever answers "what's on the menu, where are you, are you open" fastest gets the order.
Their old site didn't answer those questions quickly, and the business knew it was costing them. That's the real problem with a bad restaurant site — not embarrassment, just orders quietly going to whoever made it easier.
Constraints
This was a small local business, and that shaped every decision:
- Sub shop budget. No room for a five-figure agency engagement.
- Phones first. Restaurant traffic is overwhelmingly mobile, usually from people already in motion.
- It has to run without a web team. A sub shop doesn't have one. Whatever I shipped needed to keep working unattended.
The build
A static site, deliberately. Eight pages — home, menu, locations, jobs, privacy, terms, and a real 404 — served as plain HTML and CSS from a small Node app. No CMS, no database, no build pipeline to rot. For a restaurant whose content changes a few times a year, that's the correct architecture: fast to load, cheap to host, and almost nothing that can break at 6pm on a Friday.
That decision has held up. The site has taken 48 commits across 20 months without a rewrite, a framework migration, or a dependency emergency.
The menu is the whole product. Everything else on a restaurant site is supporting material. The menu page is what people came for, so it gets its own page, linked from everywhere, with the full menu presented as page images plus a downloadable PDF of the printed menu.
Locations and hours get their own page rather than being buried in a footer — the second question after "what do you have."
A jobs page, added a few weeks after launch. Small restaurants hire constantly, and the site was already the first place people looked.
Analytics and SEO came later, on purpose. In October 2025 I added Google Analytics, proper meta tags, a robots.txt, and a sitemap. Shipping first and measuring second isn't ideal, but it beats stalling a launch on instrumentation for a business that needed the site working.
Results
Online orders up 35% after the new site replaced the old one — a figure the business reported, not one I measured from analytics.
I want to be careful with that number. A website is never the only variable in a restaurant's month, and I didn't have analytics running at launch to isolate it. What I can point to is that the site has been live and maintained continuously since September 2024 — the version a customer loads today is one I still look after.
What I'd change
Two things, and I'd rather say them here than have you notice them yourself.
The menu should be real HTML. Right now it's images plus a PDF. That works, and it's what got shipped, but it's the weaker option: a PDF is slow on mobile, painful to pinch-zoom, and search engines can't surface an individual sandwich buried inside it. An HTML menu would let the page rank for specific items. It's the first thing I'd change, and I've written about why it matters in 7 restaurant website mistakes that cost you orders — this site currently makes the mistake I lead that post with.
Directions should be one tap. There's a locations page, but no embedded map. For a hungry person choosing between two sub shops, every extra tap is a chance to pick the other one.
Naming both is the point. A case study that only lists wins isn't a case study, it's an ad — and the useful signal for you, reading this, is whether I can tell you what's still wrong with my own work.
If your restaurant's website is losing orders to a clunky menu or a slow mobile experience, that's the kind of problem I fix. See what a site like this costs, read about my web design service, or get in touch — I'll look at your current site and tell you honestly what's costing you orders.