Restaurant operations Auckland, New Zealand · October 2026
Zaitoon
From the first call to the final bill.
I built a connected system for reservations, table service, staff ordering and branded receipts, alongside an ElevenLabs AI receptionist that helps guests book by phone.
Built around real service constraints, from competing reservations to the last table cleared.
One service, connected across the front desk and staff phones.Actual application captures · fictional demonstration data
My responsibility
Product design & full-stack implementation
Product surfaces
Customer web, iPad console & Android staff app
Core stack
React, TypeScript & Firebase
Voice integration
ElevenLabs AI receptionist
The starting point
Good hospitality needs dependable systems behind it.
Zaitoon is a Palestinian family-owned restaurant on Dominion Road in Auckland. Its identity is warm and distinctive. The software needed to carry that identity while giving the team a clearer way to manage a busy service.
The project brief centred on delays, double-booking risk and a slow, fragmented service workflow. Public customer feedback also described waiting for food, missed orders and difficulty getting a reliable answer about table availability. That feedback helped frame the problem; it does not establish which software caused an individual experience.
The design question
How can a booking, a table, an order and a bill stay connected while several people work at once?
The operational problem
Booking information and floor activity can drift apart.
Staff need to chase order status and table readiness.
Phone enquiries interrupt the people serving guests.
What I built to address it
Shared availability and server-checked reservations.
Live table states, staff ordering and visit-linked bills.
An AI receptionist for routine booking conversations.
Context: Zaitoon’s restaurant website. Customer-feedback sources and the distinction between reported issues and measured outcomes are included below.
Customer bookings
A promise the floor can actually keep.
The booking journey takes a guest from party size and available times to their details, a review step and confirmation. A private management link supports changes and cancellation. Customer bookings and staff activity use the same table inventory.
The native booking experience. Availability is checked against the restaurant’s shared inventory.
Protect the reservation
Availability is rechecked when a booking is saved. The backend claims the required tables together, so two simultaneous requests cannot both take the same capacity.
Respect the restaurant
Party size, seating duration, opening hours, cleaning buffers and arrival pacing all belong in the booking decision. A time slot is more than a free square on a calendar.
Watch the customer booking journeySee the actual booking interface move from party size and date to available times and guest details. The recording stops before making a real reservation.Read the video description
See the actual booking interface move from party size and date to available times and guest details. The recording stops before making a real reservation. This is a silent recording of the actual application with fictional demonstration data.
On the restaurant floor
Designed for the next action, mid-shift.
I made Tables the starting workspace. The iPad floor gives the host a view of the room; the staff app keeps ordering close to the table. Selecting a table brings its guests, orders and bill into the same context.
Staff browser view, also packaged for Android.
Seat. Serve. Clear. Repeat.
Find a suitable table
Use the floor or the walk-in flow, with the waitlist available when the room is full.
Take the order
Add dishes, adjust quantities and modifiers, record notes and keep the order total in view.
Keep service moving
Hold or release courses, mark items served and follow updates across devices.
Prepare for the next guest
End the visit, leave the table in cleaning, then explicitly mark it ready.
Watch the staff service workflowFollow the real service interface from selecting a table to adding dishes, reviewing the order, adding a service note and sending it. Guests, dishes and prices in this demonstration are illustrative.Read the video description
Follow the real service interface from selecting a table to adding dishes, reviewing the order, adding a service note and sending it. Guests, dishes and prices in this demonstration are illustrative. This is a silent recording of the actual application with fictional demonstration data.
The floor models 15 physical tables, including fixed and movable arrangements. Status text accompanies colour so the room does not depend on colour alone.
A branded final touch
The receipt is part of the experience.
I carried Zaitoon’s own logo into the receipt and connected the bill to every order for that visit. Staff can add a personal message; authorised roles can apply an amount or percentage discount. The preview updates before printing or export.
Actual receipt preview, with fictional guest details and illustrative prices.
Customisable details
A personal message. A consistent identity.
Restaurant brandingZaitoon logo, restaurant name, website and thank-you message.
Visit-level billingItemised dishes and modifiers across the full visit; cancelled items excluded.
Controlled adjustmentsAmount or percentage discounts, with role checks and an audit trail.
Print and sharePrint, download a PDF or share through supported browser and Android interfaces.
The bill records an amount due. It is not a payment processor or proof of payment.
The AI receptionist
A helpful first answer, with a person still in reach.
I configured a working ElevenLabs phone assistant to answer calls and help with bookings. It checks suitable times, confirms bookings and suggests alternatives when the requested time does not work. If a request escalates or needs extra help, it can transfer the caller to an employee during working hours.
Connect conversation to operations
The voice layer needs explicit booking actions and business rules: availability, reservation details, opening hours and when to hand off. A friendly voice is only useful when the booking underneath it is reliable.
Keep a clear boundary
Unclear requests and situations that need staff judgement belong with a person.
Engineering decisions
The hard part was keeping every surface in agreement.
This project extended my Flutter and Firebase experience into React and TypeScript, with backend rules shared across customer, host and staff workflows. The work was as much about state transitions, concurrency and recovery as interface design.
Customer bookingiPad host consoleStaff web & Android
Shared backend
Authenticated Cloud Functions
Validate permissions and business rules, apply transactions, reject stale changes and handle repeat requests safely.
Live snapshots bring updated service state back to the applications.
Concurrency
One capacity claim, even when requests race.
Transactional resource schedules keep table and pacing claims together. Idempotency keys make repeated requests safe, while version checks prevent an old screen from silently overwriting newer work.
Physical constraints
A table join changes more than the drawing.
Fixed and movable tables, valid combinations, occupancy and preparation state all need to agree. A visually convenient arrangement is not automatically a valid booking allocation.
Real-time service
Finishing dinner is not the same as being ready.
I modelled dining, cleaning and readiness separately. Ending a visit preserves the cleaning state until staff explicitly release the table, with updates visible across connected devices.
Reliable output
Printing needs recovery, too.
Order snapshots preserve the details sent to the kitchen. Print jobs use claim and retry states; receipt exports save the bill before producing the document and report failures to the user.
Delivery & skills
A series of engineering decisions, not just a set of screens.
I took responsibility for the interface, data model, backend commands, staff workflows and release process. The project’s records show repeated implementation and verification across web, Android, booking cutover, receipts and iPad service refinements.
Model the service
Translate restaurant workflows into bookings, physical table arrangements, visits, orders and permissions.
Build the connected product
Implement responsive React interfaces, TypeScript domain logic, Firebase authentication, transactional commands and live updates.
Handle the edge cases
Test competing bookings, repeated requests, stale edits, cancelled items, cleaning state, print retries and role restrictions.
Release and refine
Prepare signed Android releases, verify hosted assets, reconcile booking inventory and improve the iPad layout and live service updates.
Recorded milestones: signed Android release on 11 October; native booking cutover on 13 October; live service fixes on 20 October; iPad floor refinements on 22 October. The 22 October release report records 95 application checks across function, draft, integration and browser tests, plus a separate WebKit smoke test. These are dated release results, not a claim of measured restaurant performance.
What this demonstrates
Product thinking · React & TypeScript · Firebase & Firestore · API design · Transactional data modelling · Role-based access · Automated testing · Android delivery · PDF generation · Voice AI integration · Release management
What changed, and what remains to measure
The new system connects the operational steps that previously needed coordination across separate workflows. It provides shared booking inventory, live table states, staff ordering, branded bills and AI phone assistance. These are concrete capabilities; I am not claiming an unmeasured percentage reduction in waiting time or double bookings.
Browser and backend tests support the implementation. Physical printer acceptance, restaurant-specific operational sign-off and long-term service measurements are separate from those checks. The new customer booking experience is hosted; the restaurant’s original public domain remains a separate site.
Sources & demonstration notes
The product captures and recordings use the actual application with fictional guests and illustrative prices. The ElevenLabs deployment is configured separately. The engineering story is grounded in the project’s source, test suites and dated release records, reviewed on 22 October 2026.
Public reviews provide context about delays and availability communication. Double-booking risk is part of the project brief; no verified customer quote is presented as evidence of double booking. See the linked customer feedback below.
I’m looking for a full-time Software Engineer role in New Zealand. I bring production Flutter experience, hands-on React and Firebase delivery, and a habit of following a problem through the interface, backend and release.