Picking an online ordering, website and reservation stack for a small restaurant

The symptom: three systems, a fax machine and nobody owns the menu

Small restaurants rarely choose a technology stack; they accumulate one. A website built years ago, an ordering portal a vendor set up, a reservation tool someone signed up for during a slow month, plus phone orders written on pads. In one r/restaurantowners thread, a poster trying to help a parent's restaurant described an outdated website that delivered online orders by fax machine and a menu too large to read comfortably on a phone; replies pushed for a modern POS before any QR menu project (QR Code Menu?). Other owners have asked peers directly what they use for website, ordering, payment and reservations together (stack question) and how to replace a pickup portal vendor (Online order portals).

Those threads show the question is common; only excerpts of them were recorded, so they do not establish which products work. This guide therefore does not rank vendors. It gives you a way to decide that survives the next vendor change. The real diagnosis in most small rooms is not that the tools are old; it is that no one has written down what each order must do between the guest's click and the bag on the shelf.

Write the requirements list from the kitchen outward

Start at the pass, not the website. Ask where an online order must appear for the kitchen to cook it on time, whether it needs a printed ticket or a kitchen display, and whether it must fire immediately or at a scheduled pickup time. A system that sends orders to a tablet nobody watches during the rush recreates the fax problem with a nicer screen.

Then work outward: how payment is captured, how the guest is told the order is ready, how item availability is switched off when you run out, and how menu prices stay identical across in-store, website and any delivery platform where you intend them to match. Reservations sit alongside this list rather than inside it. A twelve-seat counter may need nothing beyond a phone and a waitlist; a dining room with two seatings may need deposits, party-size rules and reminder messages. Write those needs down before you look at a single demo.

POS-native ordering versus a standalone tool

A POS-native ordering module is built by the same company that runs your registers. Its main advantage is that menu items, modifiers, taxes and 86s usually live in one place, and orders arrive in the kitchen through the same routing as in-house tickets. Its main risk is concentration: switching POS later means switching ordering too, and the module's features are whatever that vendor chooses to build.

A standalone ordering tool connects to your POS through an integration or runs beside it. It may offer better design, loyalty features or marketing, and it can survive a POS change. The cost is another menu to maintain unless the integration truly syncs, and another point where an order can fail to transmit. Before choosing standalone, ask for a live demonstration of an order traveling from the guest's phone to your printer or kitchen display, including a modifier and an out-of-stock item. If the vendor cannot show that, assume you will be re-keying.

Neither is universally better. A restaurant that changes its menu weekly and has one location usually benefits from fewer moving parts. A group that wants one ordering brand across stores on different registers may accept the integration burden.

Fees, data ownership and the arithmetic of commission-free

Commission-free usually means the vendor charges a flat subscription instead of a percentage of each order, but card processing still applies, and some platforms add a fee paid by the guest. Compare tools on total monthly cost to the restaurant at your actual volume, and separately note anything charged to guests, because a guest-paid fee is still a fee your diners see. In the District of Columbia, the Office of the Attorney General's business advisory on restaurant fees says disclosure rules under the DC Consumer Protection Procedures Act apply to online platform sales as well as in-person sales (DC OAG advisory). Restaurants elsewhere should check their own state or local consumer protection authority.

Hypothetical comparison, for illustration only: a restaurant does $9,000 a month in online pickup orders. Tool A charges a flat $150 per month. Tool B charges 3 percent of online sales and no subscription. Card processing is assumed equal for both and excluded. Tool B costs 0.03 times $9,000, which is $270 a month, so Tool A is $120 cheaper at this volume. The crossover is $150 divided by 0.03, or $5,000 a month in online sales; below that, the percentage tool costs less. Run the same calculation with your own invoices and add setup fees, hardware and contract length.

Data ownership deserves equal weight. Ask in writing whether you can export guest names, emails, order history and marketing consent records in a usable file, how often, and whether that right survives cancellation. A cheaper tool that keeps your guest list hostage is not cheaper.

Making the website do one job well

For most small restaurants the website has three jobs: show hours and location accurately, present the menu in readable text, and send guests to order or book in one tap. A large menu reproduced as a photographed PDF fails the second job on a phone and fails guests using screen readers. The US Department of Justice's 2022 guidance on web accessibility explains that, under federal law, Title III of the ADA covers businesses open to the public, including goods and services offered on the web, and lists barriers such as missing alt text, poor color contrast, mouse-only navigation and unlabeled forms (ADA.gov web guidance). The guidance treats WCAG as helpful technical guidance and leaves businesses flexibility in how they comply; ask any vendor how its ordering pages perform against it.

Keep printed menus where guests want them. In the same QR thread, several commenters rejected phone-only menus while accepting a QR code as a supplement, which is a useful reminder that the website should add a channel, not remove one.

Migrating without losing orders

The dangerous week is the one when both systems exist. Old links live on social profiles, map listings, printed flyers and guests' bookmarks, and an order placed on a portal nobody is watching is a guaranteed complaint. Plan the change as a parallel run rather than a switch.

Build and test the new menu first, including every modifier, tax rule and pickup window. Place test orders and confirm each one lands at the right station. Then point every public link to the new system on the same day, keep the old portal active but monitored for a defined period, and ask the old vendor whether it can display a redirect message. Only when the old system shows no orders for an agreed number of days should you cancel it, after exporting your data.

• Export guest lists, order history and menu data from the old vendor before giving notice.
• List every place the old ordering or booking link appears and assign someone to change each.
• Run at least a week of test and live orders with someone checking both systems each service.
• Train staff on how to look up an order placed on either system during the overlap.
• Confirm notice periods and cancellation terms in the old contract before setting dates.

Keeping the menu accurate after launch

Most online ordering problems after launch are menu problems: a price raised in-store but not online, a seasonal item still for sale, a modifier that the kitchen no longer offers. Assign one person as menu owner, with a written routine for every change: update the source system, check the website and ordering view on a phone, and place a test order for any item with new modifiers. When availability changes mid-service, the 86 should happen in one place by the person who knows the walk-in is empty.

Review the online menu monthly against the printed one and the recipe costs. If your stack also feeds delivery platforms, decide deliberately whether prices match or differ there, and keep that decision visible to the menu owner so differences are intentional rather than drift.

Decision checklist before you sign anything

Use this list to compare two or three finalists on the same terms. It is a selection aid, not a ranking.

• Watched a live order travel from phone to your printer or display, with a modifier and an 86.
• Calculated total monthly cost to the restaurant at current volume and at 50 percent higher volume.
• Listed every guest-paid fee and drafted how it will be disclosed.
• Confirmed in writing that guest data and menu data can be exported, including after cancellation.
• Read contract length, auto-renewal, notice period and hardware ownership terms.
• Checked menu pages on a phone for readable text, labeled forms and keyboard navigation.
• Named the menu owner and the person who monitors both systems during migration.