Engineering partner for SaaS & platform companies.
Book a Strategy Call →Have a smaller task? Submit a quick request →Copyright 2025© Peregrine-it.com | All Rights Reserved
How we built a restaurant POS and online ordering platform for QSR chains — with offline-first tablets, kitchen display systems, multi-location sync, and payment reconciliation — serving 120+ locations and 25K daily orders at 98% uptime.
POS & Online Ordering · Offline-First
A QSR (Quick Service Restaurant) chain with 120+ locations was stuck on legacy POS hardware that couldn't integrate with their growing online ordering channel. In-store and online orders lived in separate systems — managers had to manually reconcile daily sales across two spreadsheets. When the internet went down (common in strip malls and food courts), the POS froze and locations had to turn away customers. Kitchen printers churned out orders with no digital display; during rush, tickets piled up and cooks lost track of modifiers and special requests.
They needed a unified platform: a tablet-based POS that worked offline and synced when connectivity returned, a kitchen display system that showed orders in real time with modifiers highlighted, online ordering that fed directly into the same order queue, and multi-location reporting with automatic payment reconciliation. The system had to handle 25K daily orders across 120 locations without latency or data loss.
Restaurant internet is unreliable — strip malls, food courts, and rural locations often have outages. Legacy POS required constant connectivity. When the network dropped, registers froze and locations lost sales.
Paper tickets were hard to read during rush. Modifiers and special requests got missed. There was no way to prioritize or bump orders. Cooks had to manually track which orders were in progress vs. ready.
Menu changes, pricing updates, and promotions had to be pushed to all 120 locations. There was no central source of truth — some locations ran outdated menus. Online orders sometimes showed items that weren't available in-store.
In-store POS, online orders, and third-party delivery had different payment flows. Reconciling daily sales took managers an hour per location. Discrepancies between Stripe, terminal, and internal records were common.
We built a React Native POS app that runs on tablets with a local SQLite database for offline order storage. When connectivity returns, orders sync to the cloud via a conflict-resolution protocol. The Next.js online ordering site and admin portal share the same Node.js API. Kitchen displays are web clients that subscribe to order events via WebSocket. PostgreSQL holds menus, orders, and transactions; Redis caches real-time order state. Stripe handles all payments — in-store via Terminal API, online via Checkout. A reconciliation job runs nightly to match transactions across channels.
Offline sync was the trickiest piece. We use a last-write-wins approach with server timestamps for conflict resolution. POS orders get a local UUID and sync when online — if two locations somehow create conflicting IDs (edge case), the server dedupes by order content and timestamp. We tested extensively with simulated network outages; zero order loss in production.
Mapped POS and online ordering workflows. Designed offline-first data model and sync protocol. Defined menu and modifier schema for multi-location. Evaluated Stripe Terminal for in-store payments.
Built React Native POS with SQLite and sync logic. Implemented kitchen display with WebSocket order stream. Integrated Stripe Terminal for in-store. Tested offline scenarios at pilot location.
Built Next.js ordering site with location picker and Stripe Checkout. Admin portal for menu management and multi-location rollout. Implemented reconciliation job for daily payment matching.
Rolled out to 120 locations in waves. Trained staff on POS and kitchen display. Monitored sync health and reconciliation accuracy. Achieved 98% uptime and zero order loss during rollout.
Offline-first is non-negotiable for restaurant POS. Internet in restaurants is notoriously bad — we designed the POS to assume connectivity is intermittent. Local SQLite holds everything needed to take and complete orders; sync runs in the background when the network is available. We use idempotent API design so retries never create duplicates. Zero order loss in 18 months of production.
Kitchen display drove significant operational improvement. Cooks see orders in chronological order with modifiers and special requests highlighted. Bump buttons move orders through stages (prep, cooking, ready) so the front knows when to call for pickup. The client reported a 50% reduction in modifier-related remakes after rollout.
Payment reconciliation was a hidden time-sink. In-store Stripe Terminal, online Checkout, and refunds flow differently. We built a nightly job that matches transaction IDs, amounts, and locations. Discrepancies trigger alerts for manager review. That cut reconciliation time from an hour per location to minutes.
We help hospitality and FoodTech companies build offline-capable POS, kitchen displays, and unified ordering systems. Let's talk about your architecture.