Five apps. One kitchen. Offline-first.
A modern restaurant POS designed as five purpose-built apps — POS Terminal, Kitchen Display, Captain, Owner Dashboard and chain Admin. Every terminal runs as a PWA backed by IndexedDB, so billing and KOT never wait for Wi-Fi. Swiggy, Zomato, ONDC, PhonePe and Razorpay built in.
- Three-click billing on a 10" tablet
- PWA · Dexie · Workbox sync
- Swiggy · Zomato · ONDC · PhonePe · Razorpay
- Multi-tenant Org → Outlets · 15 locales
Plugged into the restaurant ecosystem
Five apps for five roles — not one app pretending to be five.
Most restaurant POS products are a retail till with a "kitchen view" tacked on. SourceForge ships five separate apps — POS Terminal, KDS, Captain, Dashboard and Admin — each tuned to its role. They share one type-safe data model, one offline sync engine and one WebSocket fan-out, so the kitchen sees the captain's order before the printer warms up.
Offline-first, by construction
Every terminal is a PWA backed by IndexedDB via Dexie. The cart is synchronous and local; billing, KOT generation and printing never depend on network. Workbox Background Sync replays every mutation in order when connectivity returns. Wi-Fi outages stop being incidents.
Three-click billing
From item-tap to printed bill in three taps on the common path: pick item, choose tender, confirm. Touch targets are 48 × 48 px minimum. The cart is synchronous — no spinner waits, no "saving" toasts. Tax recomputes instantly. KOT prints in under 400 ms on USB ESC/POS.
Aggregators are first-class
Swiggy, Zomato and ONDC adapters ship in the box. Aggregator orders land in the same KDS queue with brand and channel tagged. Menu sync runs one-way from your master so price and availability never drift across three vendor dashboards.
Five apps. Twenty-four modules. One data model.
Each app is tuned to its role — but the underlying types, sync engine and audit log are shared. Add an outlet or a kitchen station without touching code.
The Wi-Fi went down. Service didn't.
Restaurants are the worst environment for an online-only POS — concrete walls, basement kitchens, peak-hour ISP throttling. Our entire stack runs locally first. Every order, payment and inventory change is written to IndexedDB synchronously, then queued in Workbox Background Sync. When the cloud is reachable again, mutations replay in order — captains and KDS never see a spinner.
- Dexie (IndexedDB) per terminal
- Workbox Background Sync queue
- Synchronous cart — no spinners
- KOT printing local-first
- Conflict-free replay on reconnect
- 14-day replay log preserved
Aggregators in one queue
Five adapters ship in the box — Swiggy, Zomato and ONDC for orders; PhonePe and Razorpay for payments. Orders from every channel land in the same KDS queue with brand and channel badges. Menu sync runs one-way from your master menu, so 86'd items disappear everywhere in seconds, not hours.
- Swiggy + Zomato + ONDC order pull
- PhonePe + Razorpay payment in
- Channel-tagged KDS queue
- One-way menu sync from master
- Auto 86 on stock-out (recipe BOM)
Kitchen Display + bump screens
The KDS app runs on a tablet or wall-mounted screen per kitchen station. Items route by category — pizza, grill, drinks, dessert — and bump screens advance state from received → preparing → ready → served. Captains and POS see live state. Ticket SLAs colour amber and red at configurable thresholds.
- Per-station routing by item category
- Bump screen state machine
- Ticket SLA timer (amber / red)
- Course-wise hold for fine-dine
- By-station throughput report
Captain at the table. Diner at the QR.
Two ways to skip the queue at the till. Captains take orders tableside on an Android handheld, with the KDS firing the moment they confirm. Diners scan a QR at the table, browse the same menu, and pay via UPI — the order goes straight to the kitchen, no captain hop required.
- Tableside order taking
- KOT fire from the table
- Split bill at the table
- Customer profile + history
- Tip + discount approval flows
- PIN login — no shared passwords
- Table-bound QR (no app install)
- Same menu as POS, real-time stock
- UPI intent payment at checkout
- Goes straight to KDS
- Captain-assist override available
- Customer feedback at the end
Organization → Outlets → Brands. Modelled, not bolted on.
The Admin Panel is your chain HQ. Push one menu update across forty outlets. Run four brands out of one cloud-kitchen. See consolidated GMV, food cost and wastage with per-outlet drill-down. RBAC scopes every staff PIN to the right outlet — a Bangalore cashier never sees Chennai orders.
Single independent
One outlet, one kitchen, 1–3 tills. Everything in this product, no chain features in the way.
QSR / café chain
5–200 outlets, central menu master, per-city pricing, consolidated reporting and aggregator sync from one console.
Cloud kitchen
Multi-brand from one kitchen, separate aggregator listings per brand, channel-tagged orders in one KDS queue.
Eight connectors out of the box.
Restaurants live and die on aggregator listings, UPI uptime and printer reliability. Every external integration is in our adapter framework — production-grade error handling, retry, dead-letter queue and audit trail. Adding new adapters is fixed-scope.
Five aggregator / payment adapters + ESC/POS, WhatsApp and MDM. Custom integrations are quoted; our adapter SDK is published so your IT team can build their own.
Modern monorepo. Five apps. Six packages. Two services.
pnpm + Turborepo monorepo. NestJS REST + WebSocket on PostgreSQL 15 with TimescaleDB hyper-tables for analytics. Type-safe shared packages across the five PWAs. Redis for fan-out. Prisma at the data layer.
- POS Terminal · port 4501 · PWA
- KDS · port 4502 · PWA tablet
- Captain · port 4503 · Android-first
- Dashboard · port 4504 · live KPIs
- Admin Panel · port 4505 · HQ console
- Outfit font · 48×48 px touch targets
- NestJS REST + WebSocket · port 3900
- 16 modules — orders, kitchen, menu, tax…
- Prisma ORM · PostgreSQL 15
- TimescaleDB for analytics hyper-tables
- Redis for queues + WebSocket fan-out
- JWT 15-min access + 7-day refresh rotated
- Dexie (IndexedDB) per terminal
- Workbox Background Sync queue
- Conflict resolution: last-writer-wins + audit
- Sync engine package shared across all apps
- Replay log preserved 14 days
- Manual conflict review in Admin
- 5 adapters — ondc, phonepe, razorpay, swiggy, zomato
- ESC/POS package (USB / BT / network)
- i18n package — 15 locales
- Type-safe shared types package
- Currency / tax / dates utils
- Aggregator menu sync (one-way master)
Every shape of restaurant.
Single-counter cafés to 200-outlet QSR chains, fine-dine to cloud kitchens to food trucks — the same stack adapts to your format on day one.
Six phases. Single outlet in 2–3 weeks.
The same playbook our team has run across restaurant rollouts of every size. Discovery first, written SOW, weekly milestones, supervised cutover — and on-site for the first 72 hours.
SourceForge consultant on-site at every outlet for the first 72 hours of go-live. Real human, real time.
Discovery
Outlet survey, current POS audit, aggregator listings, KOT stations, payment providers, staff roles.
Configure
Menu master, tax setup (dine-in / takeaway / delivery), KOT routing, staff PINs, printer mapping.
Migrate
Menu, customers, loyalty balances, historical orders from Petpooja / Posist / Toast / custom POS.
Train
Cashiers (POS Terminal), captains (Android app), kitchen (KDS bump flow), owner (Dashboard).
Go-live
Phased cutover during a low-cover window. Consultant on-site for the first 72 hours.
Hypercare
4 weeks of daily standups, then SLA-based managed support + quarterly business reviews.
Real SLAs, calibrated to a busy Friday night.
Two restaurant stories — placeholders till the real ones land.
Real customer names and metrics available on a discovery call.
Eighteen outlets on a legacy POS that couldn't handle Swiggy + Zomato + ONDC. Aggregator menus drifted weekly; 86'd items kept selling online; daily reconciliation took the finance team six hours; Wi-Fi outages stopped billing every other week.
Migrated to SourceForge Restaurant POS across all 18 outlets in 9 weeks. Onboarded all three aggregators via the adapter framework. Switched to offline-first PWA on tablets. Plugged TimescaleDB analytics into the owner dashboard.
- Wi-Fi outage → billing impact: eliminated
- Aggregator menu drift: weekly → zero
- Daily reconciliation: 6h → 25 min
Four delivery brands operated out of one kitchen on three separate vendor dashboards. Captains keyed orders from screens to printers manually; kitchen got the wrong KOT 5% of the time; brand-level GMV took a day to compile.
Deployed SourceForge with multi-brand setup, four aggregator listings synced from one master menu, channel-tagged KDS queue and per-brand reporting. Brought all four brands onto one Captain app + KDS.
- Wrong KOT rate: 5% → 0.2%
- Brand-level GMV: T+1 → real-time
- Average order assembly time: −38%
Common questions
Purpose-built. The system is five apps designed for five roles — POS Terminal for the cashier, KDS for the kitchen, Captain for floor staff, Dashboard for the owner, Admin for the chain operator. Three-click billing, course-wise KOT routing, aggregator order merging, kitchen bump screens, table maps with split/merge, station printing — none of it bolted on from a retail POS.
30-minute demo sized to your format — café, QSR or cloud kitchen.
Tell us your format (single outlet / chain / cloud kitchen), aggregators in scope and 2–3 things your current POS can't do. We'll demo with a configured sandbox using your real menu and channels — not a generic vendor reel.
- 30-minute discovery + tailored demo
- Live POS + KDS + Captain walk-through
- Aggregator + payment adapter deep-dive
- Migration plan from your current POS