Skip to content
All work

Case study

  • Hospitality
  • Mobile
  • React

FoodCircle

A booking client for restaurants. A guest opens a venue, picks a date, a time and how many people are coming, and the table is held. The restaurant gets a reservation with all four of those on it.

  • Java
  • React
A restaurant window at night seen from a wet pavement, the dining room lit warm inside — laid tables, candles and wall lamps — behind dark glass.
Role
API, front-end and the booking flow
Built with
Java · React

The challenge

Guests were booking by message. A message carries a sentence, not a booking: no guest count the kitchen can plan against, no slot the floor can hold, and no record afterwards of who asked for the table or whether anyone answered. Two people asking for the same evening in two different threads is a double-booking nobody can see until they both arrive.

What we built

  • A venue card that answers the first questions

    Cuisine, phone number, today's hours, the address on a map and what a meal costs. The things a guest checks before they will consider booking, on the screen before the booking control.

  • Guest count, date and time as fields

    Covers on a stepper, the date on a calendar, the time as a slot you tap. Each one is a value the reservation carries, rather than a phrase in a message someone has to read and interpret.

  • Slots, not open-ended requests

    A time is chosen from what the venue actually offers. A guest cannot ask for a time that was never available, which is most of what a message thread gets wrong.

  • Java API behind a React front-end

    Venues, hours and slots live behind the API. The client renders what the API says is bookable and posts one reservation back.

  • The reservation is a record

    Venue, date, time and covers on one row. It exists after the conversation ends, which is the whole difference between a booking and a message.

Technical approach

Venues and their slots sit behind the API, so availability is decided in one place rather than in whichever thread the guest happened to use. A reservation is a row carrying its venue, date, time and covers — four fields, all of them required, none of them free text. The chat apps are deliberately out of the path: a booking that lives in a message is a booking the restaurant cannot count, cannot hold and cannot look up later.

The product

The venue screen on a phone: the restaurant's name and cuisine with its logo, phone number and today's hours, a star rating and review count, average price, a menu link, the address and a map with the venue pinned, and a Book button.
Screens from the booking client.
The reservation screen on a phone: a stepper for the number of guests, a June calendar with the twenty-first selected, a row of time slots with 6:30 PM chosen, a choice between a free and a customised reservation, and Next.
Guest count, date, time — the four fields a reservation carries