Development Agency
Contact Sign in Get a project quote

Service

Restaurant website development

For restaurant owners and small groups who need a website, table booking and menu system designed around their actual floor, service periods and kitchen rather than a third-party reservation widget that treats every table as the same.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A restaurant sells seats for a window of time, and the money is made or lost in how well the floor is turned.

  • Most independents run bookings through a reservation widget that charges per cover, a paper book on the host stand and a phone that rings during service.
  • The widget knows nothing about the room: it books a party of two onto the six-top by the window at seven o'clock on a Saturday because a slot was free, and the eight-strong birthday enquiry that came by email the same afternoon is turned away.
  • The host is left juggling table moves on the paper book while the queue builds at the door.

Where it gets harder

Turn times are set once and never revisited, so lunch tables are booked for two hours when they turn in seventy minutes, and Friday dinner is booked for ninety when it runs to two and a quarter.

  • No-shows on a Saturday cost a full cover and the deposit policy is whatever the manager remembers to say on the phone.
  • The menu lives in three places: a PDF on the website that is a month out of date, the chalkboard, and the kitchen's own list of what is on tonight and which dishes carry which allergens.
  • Private dining enquiries arrive by email and sit unanswered during service.
  • The owner cannot see cover counts by service period, which days no-shows cluster on, or whether the website is actually bringing diners in.

Scope of the service

What the build covers

A custom restaurant build normally covers:

  • The website itself Built around menus and booking rather than a brochure
  • A table plan with named tables Capacities and joinable combinations
  • Service periods with their own turn times Pacing limits and last-booking times
  • Online booking That allocates to real tables with the host able to move parties
  • Deposits or card holds for parties above a size you choose
  • A waiting list for full services
  • A no-show policy applied and recorded automatically
  • Menu management with sections Dishes, prices, daily specials and the allergen and dietary tags your kitchen records against each dish
  • Private dining and event enquiry forms that reach the right person
  • Opening hours and menus per site where there is more than one

How discovery works

Discovery works through a full Saturday with you: when the first sitting is seated, how the host decides which tables to hold back for walk-ins, how a party of nine is squeezed onto two joined tables, whether the bar takes bookings at all, how the kitchen tells front of house that a dish has sold out, and who changes the menu online and when. Each answer becomes a named workflow stage in the scope document.

  1. Request
  2. Table assignment
  3. Confirmation
  4. Reminders
  5. Seated
  6. Feedback. Where the restaurant already uses a reservation system it wants to keep
  7. The scope names the integration point rather than replacing it

Deliberately out of scope

  • The till itself, stock and purchasing, payroll and rota software. Those stay in the tools you use and we connect to them where a connection is worth its cost

When the scope grows

Scoping scenario

A three-site group wants one website with a site chooser, separate table plans and service periods per site, a shared menu library where head office writes dishes and each site switches them on, and a group-level view of covers, deposits and no-shows. That is a materially different build from a forty-cover neighbourhood bistro with one service a night, and the scope document says which one you are buying.

Deliverables

What you receive

  • Discovery notes from a walk-through of a full service day on the floor and in the kitchen
  • A written scope document naming each stage from booking request to post-visit feedback, with what is out of scope
  • Design of the public site, the booking flow, the host table-plan view and the menu editor on phone, tablet and desktop
  • The build, deployed to your hosting or ours
  • Migration of future bookings, regular guests and menus from your current widget or book, where relevant
  • Training for the host team, managers and whoever edits the menu, with a short written guide
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts and a look at your current website, reservation widget, paper book and how the menu is published today.

    Project stage: Onboarding

  2. Planning

    Discovery with the owner, a manager and the head chef; the scope document and milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the booking flow, the host view of the table plan and the menu pages, checked on the host stand tablet and a diner's phone.

    Project stage: Design

  4. Development

    Built in stages: table plan and service periods first, then online booking and deposits, then menus, enquiries and reporting.

    Project stage: Development

  5. Client review

    The host team runs a test week alongside the old book on real booking patterns and tells us where allocation or turn times are wrong.

    Project stage: Client review

  6. Revisions

    Pacing rules, table combinations and the menu editor are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Future bookings migrated, reminders tested on numbers you control, the old widget redirected, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The restaurant runs on the new site and booking system; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card payment providers for deposits, card holds and private dining balances
  • SMS and email providers for confirmations, reminders and post-visit feedback requests
  • Existing reservation systems the restaurant wants to keep, where they expose a connection
  • Till and EPOS systems for covers and spend per booking
  • Accounting software for deposit reconciliation
  • Google Business Profile and map listings for opening hours and the booking link

How we would approach it

Worked example

Concept demo

A two-room restaurant with a hold-back for walk-ins

The situation

A sixty-cover restaurant with a main room and a smaller back room wanted online booking without losing the walk-in trade that filled the bar tables.

Why it is a custom build

This needs a custom build rather than an off-the-shelf widget because the restaurant's rules are about the room, not the slot: which tables exist online, how fast the kitchen can be fed, and when a booking stops being a booking and becomes an event enquiry.

The scope we would propose

  • The table plan marks six bar tables as never bookable online
  • Each service period carries a pacing limit so no more than a set number of covers can be seated in any fifteen minutes
  • The back room is bookable as a whole for private dining through an enquiry form rather than the public booking flow
  • Parties of seven or more pay a deposit per head that is released against the bill

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of sites and whether menus and table plans differ between them
  • Size of the table plan and whether tables are joinable for large parties
  • Service periods, pacing rules and turn times that change by day
  • Deposits or card holds for large parties and the payment provider involved
  • Whether an existing reservation system is kept and connected rather than replaced
  • Menu complexity: specials, set menus, tasting menus, allergen and dietary tags per dish
  • Private dining and event enquiry handling
  • Volume of future bookings and guest records to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Restaurant booking package

Table booking with a real table plan, service periods and turn times, large-party deposits, waiting list, menus with allergen tags and private dining enquiries for independent restaurants.

Custom build
View the package

FAQ

Frequently asked questions

Would the package be enough, or do we need a custom build?

If your restaurant has one site, a conventional table plan and standard service periods, the restaurant booking package usually covers it through configuration. A custom build is the honest recommendation when several sites share a menu library, when pacing and table rules are unusual, or when a reservation system you already use has to stay in the picture. Discovery is where we tell you which.

Can we keep the reservation system we already use?

Often, yes. Where the system exposes a connection we can build the website around it and add the menu, enquiry and deposit layers on top. Where it does not, the scope document says so plainly and sets out what moving away would involve.

How are allergens shown on the menu?

The kitchen records allergen and dietary tags against each dish in the menu editor and the website displays exactly what has been recorded, with a note that diners should speak to staff. The system is a way to publish what your kitchen knows; checking and keeping that information correct remains the restaurant's responsibility.

Who owns the website and the booking system afterwards?

You do. Source code and your data are handed over at delivery; hosting and maintenance are optional and separately agreed, and the system can be moved to another provider.

Can you move our future bookings across?

Usually. We export from the current widget or transcribe the paper book for the weeks ahead, map parties to tables in the new plan and switch over between one service and the next. What can be carried over is stated once we have seen the data.

Get a project quote for restaurant software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences