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

- 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


Got something like this to build?
Start a conversation