A restaurant website costs between roughly nothing and about $25,000, and most restaurants belong near the bottom of that range. The build is rarely where the money goes. Ordering commission is, and a site that quietly moves a slice of your regulars off the marketplaces is worth more than any amount of design.
Here is what the bands actually look like, and what pushes you from one to the next.
What a restaurant website costs
| What you get | One-off build | Ongoing |
|---|---|---|
| Template site: menu, hours, map, phone, a link out to ordering | $0 - $1,500 | $20 - $60/mo hosting |
| Designed single-location site: proper menu pages, reservations, ordering embedded | $2,000 - $7,000 | $50 - $250/mo |
| Custom build: native ordering, catering enquiries, gift cards, loyalty tie-in | $8,000 - $20,000 | $150 - $600/mo |
| Multi-location group: location templates, store locator, per-site menus and ordering | $15,000 - $45,000+ | $300 - $1,500/mo |
Star Force Solutions starts from $200 as a minimum, never a fixed price. A one-page site for a taqueria that needs a menu, a map and a phone number sits near that floor. A twelve-site group with a franchise ordering stack does not, and anyone who quotes that off a web form without asking which POS you run is guessing.
What moves the number:
- How many menus you run. One menu is a page. Brunch, dinner, happy hour, catering and a rotating specials board is a small content system.
- Whether ordering lives on your domain or you link out to a provider's hosted page.
- Photography. A shoot of your actual food runs $800 - $2,500. Stock photos of somebody else's tacos cost you credibility instead.
- Number of locations, and whether their menus and prices differ.
- Who writes the content. Hand over menu text, hours and a story and you save real hours of billable time. Make the agency chase you for weeks and you pay for that too.
Most of this is ordinary web design and development, and for a small independent the right answer is often a deliberately simple Squarespace or Wix build. If you have several menus, a blog and plans to add more, WordPress earns its keep.
Online ordering versus the third-party apps
This is the decision with real money attached. Marketplace commission is published: DoorDash, Uber Eats and Grubhub all sell tiered plans that typically run around 15%, 25% and 30% of the order subtotal for delivery, with pickup usually charged somewhere between 6% and 15%. The higher tiers buy more visibility inside their app.
Do the arithmetic on your own numbers rather than mine. Four hundred delivery orders a month at a $38 average ticket is $15,200 of gross sales. At 30% that is $4,560 handed over every month. Push the same volume through ordering on your own domain and you pay card processing of roughly 2.6% to 2.9% plus $0.10 to $0.30 a transaction, plus a platform fee. Flat-fee providers such as ChowNow or Owner.com sit in the low hundreds per month; Toast and Square charge per order or bundle it into the POS. Call it $650 to $900 all in at that volume.
The gap is around $3,600 a month, but it is only real for the orders that actually move. Nobody switches all of them, and you should not try.
Think of it as demand ownership:
- The marketplaces are a discovery channel. Somebody scrolling for Thai food at 7pm had no intention of visiting your site. That commission is marketing spend, and it is often worth paying.
- Your site is for people who already know your name. Anyone who searches for your restaurant, taps your Google Business Profile or scans the QR code on the table is a customer you already paid to acquire. Paying 30% on that order is a leak.
Things that shift orders across, none of which need a big build:
- Put ordering first on the page on mobile, above the fold, not buried in a hamburger menu.
- Set the ordering link in your Google Business Profile to your own page rather than the marketplace.
- Drop an insert with a direct-order code into every delivery bag. The people opening those bags already like your food.
- Price direct at or below the app price. App menu prices are commonly inflated 15% to 20% to cover commission, so you can undercut yourself and still net more per order.
The honest exception: if you take thirty online orders a week, do not commission a custom checkout. A free Square Online ordering page linked from a clean site is the right call. Direct ordering starts paying for itself somewhere north of a few hundred orders a month, and the ROI calculator will run that on your figures. A full e-commerce build is for groups selling merchandise, meal kits or gift cards at volume, not for one dining room.
Reservations: what to pay for and what to skip
Reservation software is priced two ways. OpenTable charges a monthly base plus a per-cover fee for diners who arrive through their network, which is why it feels expensive on a busy Saturday. Resy and SevenRooms are mostly flat monthly. Tock is built around prepaid tickets and deposits, which suits tasting menus and anywhere that bleeds from no-shows.
Worth paying for:
- Deposits and card on file. Lose a four-top on a Friday and you have lost the table twice: once for the booking, once for the walk-in you turned away.
- Guest history. Knowing it is somebody's third visit and that one of them cannot eat shellfish is the actual product.
- Reserve with Google. Booking straight from the search result removes a step, and every supported provider offers it.
Worth skipping: network cover fees, when your bookings are mostly people who searched your name anyway. If you are a 40-seat neighbourhood room that rarely turns anyone away, a free waitlist tool and a phone number will do the job. Where you can, keep the booking widget on your own domain so the email address lands in your list rather than somebody else's.
A menu search engines and AI assistants can read
The most common fault on restaurant sites is a menu that is a PDF or a photo of a chalkboard. Google cannot index a price inside a JPEG, an assistant answering "who does gluten free pasta near me" cannot read it, and a customer on a phone has to pinch and zoom.
A readable menu looks like this:
- Real HTML text: item name, description and price as text on the page.
- Sections marked with proper headings, so a machine can tell starters from mains.
- A stable URL. When the menu changes seasonally, change the content and keep the address.
- Dietary and allergen tags written out in words — vegan, gluten free, nut free — because that is what people type.
- Restaurant structured data covering address, opening hours, cuisine, price range, the menu URL and whether you accept reservations.
- Prices maintained in one place. If the POS holds the truth, feed the site from it rather than retyping and letting the two drift apart.
That same HTML is what large language models read when somebody asks an assistant where to eat, which is the whole basis of generative engine optimisation. There is no separate trick for it. A menu written as text is legible to both.
Speed matters more here than on most sites, because menus get opened on a phone with two bars while somebody stands on the pavement outside deciding. Run your menu page through a speed test and read the mobile number, not the desktop one. A hero video and four custom fonts are usually the culprit.
Multi-location without splitting yourself in half
One domain. One page per location in a consistent folder structure, each with its own address, hours, phone number, map, menu and ordering link. Separate domains per site is the mistake groups make most often: you divide whatever authority you have across several weak sites and multiply the maintenance.
The exceptions are real but narrow — genuinely separate brands, or franchisee-owned sites whose content you do not control.
What multi-location adds to the build:
- A location template, so opening number seven is a form entry rather than a rebuild.
- Per-location structured data and a claimed Google Business Profile for every address, which is where most of the map visibility comes from. That is local SEO work rather than web design work, and it carries on after launch.
- Menus that differ by site, including price differences between a downtown room and a suburban one.
- A store locator that renders as HTML rather than assembling itself only in JavaScript.
- Review handling per location, so one bad month at one address does not follow the group around. That is what reputation management is for.
How to brief this so the quote means something
Before you ask anyone for a price, write down: how many locations, how many menus, which POS you run, whether ordering will be direct or linked out, whether you take reservations and on what, and who owns the domain today. That single page turns a vague quote into a comparable one.
Then ask any builder three questions. Do I own the domain and the hosting account. Can I change a menu price myself without raising a support ticket. What happens to the site if we stop working together. If any of those answers is awkward, keep looking.
Our bands and what sits inside each are on the pricing page, and the sector work is set out under restaurants and food. If you would rather talk it through with your own numbers in front of you, get in touch — we are based in El Paso and work with restaurants across the US.
