Restaurant Management System
Six interconnected applications for a restaurant in Belgium — ordering, operations and kitchen hardware — built and deployed by one developer.
Role
Solo Developer (End-to-End)
Duration
5–6 months
Client
Belgium
Status
In Production
6
Platforms Built
1
Developer
5 mo
Duration
94+
Lighthouse Score
Context
How this project started
The restaurant was running on a Wix-based system that scored 47 on Lighthouse and did not match how the business actually worked. Two developers had already tried to replace it by cloning the existing site, which reproduced the problems rather than solving them. I started somewhere else: with questions. Once the owner confirmed I had understood his business, I built the system it actually needed.
The problem
The restaurant was running on a Wix-based system that scored 47 on Lighthouse and did not match how the business actually worked. Two previous developers had tried to replace it by cloning the existing site in React, which reproduced the problems rather than solving them. The owner needed a system built around his real workflow — his menu rules, his delivery zones, his kitchen — not a faster copy of what he already had.
Constraints
- One developer, end to end — no team to hand any layer off to
- Working from Pakistan for a client and physical hardware in Belgium, roughly 6,000 km away
- A thermal printer in the restaurant kitchen that had to print silently, with no staff interaction
- Requirements grew during the build; the timeline and the relationship both had to survive it
- Staff are not technical — the dashboards had to be usable without training
What I built
Rather than one large application, the system is six focused ones sharing a single server, so each audience gets an interface built for its job. Customers order through an installable PWA. The owner and front-of-house staff each get a dashboard scoped to their role. A React Native app handles the owner's phone. An Electron agent sits in the kitchen and prints receipts silently. Everything stays in step through a central Node server pushing real-time events, so an order placed on the website appears on the dashboards and comes out of the kitchen printer without anyone refreshing anything.
How it fits together
- Node.js and Express server organised as self-contained feature modules, each owning its own validation, routes, controller and service
- MongoDB for persistence, with Redis caching authentication so most requests never touch the database
- Dual WebSocket transport — Socket.IO for the browser clients, native ws for the Electron printer agent
- Zod schemas drive both request validation and the generated Swagger documentation from one definition
- Real-time events update TanStack Query caches surgically rather than triggering full refetches
Running in production
Runs on a Hostinger VPS in Europe, chosen for proximity to Belgian users — around 30–120ms of database latency for them, against 100–300ms had it been hosted near the developer. The dashboards are deployed as independent apps on subdomains sharing one server. Images are delivered through Cloudinary.
My role
- Requirements discovery — establishing the actual problem before any code was written
- System architecture across all six applications and the shared server
- Every line of frontend, backend, mobile and desktop code
- Deployment, server configuration and post-launch maintenance
- Direct client communication, and mediating between the client and the agency when scope tensions arose
Outcome
- Lighthouse performance went from 47 on the previous Wix-based site to 94+ on desktop
- Orders flow from the customer's phone to a printed kitchen receipt without staff intervention
- The system is in production and still maintained
- Solved the thermal-printer integration that had blocked previous developers entirely
Last updated
System Design
Architecture
A custom restaurant ordering and management platform for a Belgian restaurant, built solo over five to six months. Six interconnected applications — a customer PWA, two staff dashboards, a mobile admin app, a thermal-printer desktop agent, and the server that ties them together.
Client Layer
Public PWA
Next.js · TypeScript
Admin Dashboard
Next.js · TypeScript
Receptionist Panel
Next.js · TypeScript
Mobile App
React Native
Server Layer
Node.js · Express
Modular architecture with dual WebSocket transport — Socket.IO for web clients, native ws for the Electron printer. JWT auth with Redis session caching. Auto-generated API docs via Zod + Swagger.
Data & Infrastructure
MongoDB
Germany (co-located)
Redis
Session cache
Electron App
Thermal printer
Cloudinary
Image CDN
What I Built
The Platforms
Each platform was purpose-built for its users — different interfaces, different priorities, same underlying system.
Public-Facing Web App (PWA)
A customer-facing progressive web app for browsing the menu, customizing items, and placing orders with pickup or delivery.
- Menu browsing with category navigation
- Item customization — toppings, extras, exclusion rules
- Pickup and delivery ordering with time scheduling
- Installable on Android and iOS — no app store required
- Smart two-finger map interaction with auto-unlock
- Mobile-first bottom drawer for item customization
Admin Dashboard
A comprehensive management panel where the restaurant owner controls every aspect of the business.
- Full menu management — items, categories, toppings, customization rules
- Delivery zone management with dynamic fee structures
- Operating hours and restaurant availability control
- Content, SEO, and social media management
- Staff management with role-based access
- Order management with direct receipt printing
- Real-time notifications and bulk operations
- Drag-and-drop reordering for categories, items, and zones
Receptionist Dashboard
A dedicated panel for front-of-house staff to process orders and access restaurant information.
- Process and manage orders — update statuses, view details
- Create orders on behalf of customers (pickup or delivery)
- View operating hours, delivery zones, and fee structures
- Manage active login sessions
- Real-time sync with admin dashboard
React Native Mobile App
A mobile app for the restaurant owner to manage orders and toggle availability on the go.
- Real-time push notifications for new orders
- Order management — search, filter, update status
- Restaurant open/close toggle
- Share order details to WhatsApp with Google Maps links
Electron Thermal Printer App
A desktop application that silently prints order receipts — no dialog boxes, no user intervention.
- Silent printing — zero user interaction required
- Print queue with multi-level retry logic
- Network-level and WebSocket reconnection handling
- Operational logging for remote debugging
Server & Real-Time Architecture
The central backend powering all platforms with real-time synchronization.
- Modular architecture — each feature is a self-contained module
- Dual WebSocket transport — Socket.IO for web, native ws for Electron
- Redis-based session caching — eliminates DB calls per request
- Automatic API documentation via Zod + Swagger
- Surgical TanStack Query cache updates over WebSocket
- Offset-based pagination optimized for admin interfaces
Visual
Screenshots
Deep Dives
Two parts worth their own page
Problem Solving
The Hardest Problems
Every project has moments that test what you’re made of. These were mine.
The Thermal Printer
“Previous developers had been stuck at exactly this point.”
The printer was sitting in the client's restaurant kitchen in Belgium. I was working from Pakistan.
There was no YouTube tutorial, no blog post, and no ready-made guide for what I needed to do — connect to that specific thermal printer model, send structured payloads, and trigger silent printing without any user interaction.
I started with deep research: reading the printer's user manual, scouring documentation, and piecing together anything that could point me in the right direction.
I tried, failed, tried again, and failed again. But I kept at it. Eventually, the printer was responding — the Electron app was listening for WebSocket events from the server, sending formatted data, and the printer was producing receipts on the other side of the world.
I deliberately tackled this before starting the main project. Previous developers had been stuck at exactly this point. I built a test app and a sandbox server — once I confirmed the receipt printed successfully from Pakistan to Belgium, I knew the rest of the project was viable.
Understanding the Business
“Everything you built already exists in my current Wix setup. You haven't added anything.”
The client came to me saying, "I'm using this Wix-based system, but it's not what I want." The developers he had worked with previously had simply looked at his Wix website and started cloning it in React.
I took a different approach. I listened. I asked questions. I explained my understanding back to him, sought clarification, and did independent research before writing any code. I documented my interpretation and shared it with him.
When he finally said, "Yes — now you understand. I'm very happy. Go build it," that was when development began.
Learning React Native in 10 Days
I had ten days to build the admin mobile app. In the first eight days, I learned React Native from scratch, built four practice apps, and tested everything end to end.
One of those practice apps was a mini social media platform — authentication, CRUD, posting, liking, commenting, and real-time notifications via FCM.
On day nine, I started building the actual production app. I delivered it on day twelve. It was reviewed and approved.
Engineering
Key Decisions
The choices that shaped the system — and why I made them.
API v1 → v2 Migration
When the client requested separate dashboards, I migrated the entire server from a flat structure to a modular architecture.
- Each feature became a self-contained module (validation, routes, controller, service)
- Zod schemas drive both validation and Swagger documentation automatically
- Redis caches authentication results — subsequent requests skip the database
- Dual WebSocket architecture: Socket.IO for web clients, native ws for Electron
- Clean internal API lets any HTTP module trigger real-time events
Web Apps Over Desktop Apps
The client initially wanted desktop applications for both dashboards. I proposed web apps instead.
- Updates deploy instantly — no download/install cycles
- Cross-platform by default — Chrome, Safari, Edge, any OS
- Independent apps on subdomains, sharing the same server
- Significantly lower maintenance overhead
Infrastructure Proximity
Hosted on a Hostinger VPS in Europe — chosen for geographic proximity to Belgian users.
- MongoDB co-located with the server, close to the people using it
- Database query latency: ~30–120ms for Belgian users vs. 100–300ms from Pakistan
- Cloudinary CDN for image delivery and optimization
Results
The Numbers
Lighthouse desktop scores — before and after.
Before
47
Wix-Based Website
Wix
After
94+
Custom Platform
Next.js
60+ on mobile (Lighthouse applies 4× CPU throttle)
Beyond the Code
The Human Side
“This project survived because of you.”
— Both the client and my CEO
Mediated conflict between the client and my CEO when tensions arose around scope and expectations
Managed requirements creep without derailing the timeline or the relationship
Built the entire system solo — every frontend, every backend, every deployment
Technology