How We Built Kafe Kufe from Scratch: A SaaS Technical Deep Dive

When we decided to build Kafe Kufe, we had a choice most product teams don't get: we could take as long as we needed on discovery. So we spent four weeks in cafes before writing any code. This document is about what we built after that — the real technical story.

The core technical requirements that shaped every decision

Restaurant environments are hostile to software. Unreliable internet. Staff who have never used a smartphone for work. Owners who need the system to just work, every single day, without a technical team to maintain it. These constraints shaped everything.

The requirements that mattered most: offline-first operation (the POS had to work even when the internet dropped), real-time sync across devices (an order placed on a QR table ordering screen had to appear on the kitchen display instantly), sub-second performance for POS interactions (staff can't wait two seconds for a tap to register), and a UI simple enough to train new staff on in under twenty minutes.

Architecture: Why we chose Firebase over a traditional backend

The real-time sync requirement and offline-first requirement together pointed strongly toward Firebase Firestore. Firestore's offline persistence and real-time listeners gave us both capabilities with significantly less custom infrastructure than a traditional REST API + WebSocket setup would have required.

The trade-offs were real: Firestore's query limitations forced us to denormalise our data model more aggressively than we'd have preferred, and cost management required careful indexing and read minimisation strategies. But for a team of our size building a product with real-time requirements, it was the right call.

The PWA decision and what it cost us

We built Kafe Kufe as a Progressive Web App rather than a native mobile application. The reasoning: faster iteration cycles, a single codebase for all form factors (phone, tablet, desktop), and no app store dependency for updates. In an industry where restaurants might be running an Android version from 2019, the ability to push updates without waiting for store approval was significant.

What it cost us: PWAs have limitations on iOS that we constantly battle — push notification delivery, home screen installation prompts, and background sync are all more restricted than on Android. For a product targeting the Indian market where iOS penetration is lower than global averages, this was an acceptable trade-off. For a Western market, we'd reconsider.

QR table ordering: the engineering details

Each table gets a unique QR code that encodes a URL containing the restaurant ID and table ID. When a customer scans, they land on a menu page that loads the current menu from Firestore in real-time — so if a dish sells out, it disappears from the menu immediately. Orders are written directly to Firestore, which triggers a real-time update on the kitchen display and the POS.

The session management required careful thought: customers needed to be able to add to their order over time without losing context, but we couldn't require account creation. We solved this with a device-fingerprinted anonymous session tied to the table's active dining period, with session cleanup triggered when the table was marked as settled.

Payment integration: the India-specific challenges

India's payment landscape is complex in ways that products built for Western markets don't anticipate. UPI (Unified Payments Interface) is dominant for small transactions, but the reconciliation process differs significantly from card payments. Cash is still significant for a large percentage of transactions. And the regulatory requirements around GST invoicing are specific, enforced, and non-trivial to implement correctly.

We integrated Razorpay for card and UPI payments, built a custom GST invoice generator that correctly handles CGST/SGST/IGST splits depending on B2B or B2C transaction type, and designed a cash reconciliation flow that matched how actual cashiers think about end-of-day settlement.