Products I've built

Unified billing, kitchen, table management, and checkout — one order data model across 4,200+ restaurants.

The fundamental problem with restaurant POS wasn't any individual module — it was that billing, kitchen, and payment were three separate systems that had to be manually kept in sync. I redesigned around a shared order record that all modules read from and write to. The result: eliminating the re-keying step that was adding 29 seconds to every checkout and causing a significant fraction of billing errors.

• Unified order model — billing, KOT routing, table management, menu, and payment operate on the same record with no data translation between systems
• Offline-first local store with deferred cloud sync — service runs normally during network outages; no lost orders, no manual recovery
• Checkout time from 47s to 18s — not through UI changes, but by removing the re-keying step between kitchen confirmation and billing
• Billing errors down 34% across 4,200 outlets — directly from eliminating manual data re-entry
• Multi-format support across QSR, fine dining, cloud kitchens, bars, and multi-cuisine — one codebase, configurable workflows

Role-specific apps for every position in a restaurant — designed for constrained hardware and operational pressure.

Restaurant hardware is not developer hardware. These apps run on EDC terminals, low-RAM Android tablets, kitchen display screens, and budget phones — under flaky networks, in kitchens with grease-covered screens, used by operators who cannot stop service to troubleshoot. I built the Android product line with those constraints as the primary design inputs, not afterthoughts.

• Role-specific applications: billing terminal, captain order-taking, kitchen display system, and management dashboard — each optimised for the specific workflow and device
• Offline-first transaction handling on every app — local persistence with deferred sync; no transaction is lost during connectivity drops
• OTA update channel with phased fleet rollouts and automatic rollback on elevated crash rates — 8,500+ devices updated without service disruption
• 99.1% crash-free session rate across 8,500+ active devices at peak restaurant hours
• Hardware-agnostic: runs across EDC terminals, Android tablets, phones, and KDS screens with consistent behaviour

One menu change. Every outlet, aggregator, and ordering channel updated automatically.

Before this system existed, a 200-outlet chain pushing a price change meant manually updating each aggregator, each outlet's POS, and the ordering website — often over 3 days, often with inconsistencies. I built the catalog as infrastructure: a hierarchical data model with inheritance rules that makes a single change propagate everywhere automatically, with version control and rollback for safety.

• Hierarchical model — category → item → variant → modifier — with pricing, availability, and tax rules that inherit from parent and override at any level
• Propagation time from 3 days to under 4 hours for 200-outlet chains — fully automated, no aggregator ops team
• Bulk operations across all outlets simultaneously: price changes, availability toggles, new item rollouts — one action, all channels
• Multi-channel sync: POS, Swiggy, Zomato, web ordering, and QR menu updated from one change — now serves 15,000+ outlets
• Version history and rollback — menu experiments can be reversed across live outlets without downtime

Orders from every channel — web, app, aggregators, QR — flowing directly into the POS and kitchen without manual entry.

The order acceptance problem in online ordering isn't the ordering interface — it's what happens after the customer places the order. Before this platform, aggregator orders required a staff member to read the screen and re-enter into the POS. That step introduced errors, delays, and the possibility of a missed order during a busy period. I built the platform to eliminate that step entirely.

• Orders from web, app, Swiggy, Zomato, and QR menus auto-injected into POS and KOT without manual acceptance or re-entry
• Real-time menu availability sync — out-of-stock items on POS propagate to all ordering channels in under 5 minutes
• Order defect rate reduced 52% by removing manual entry from the acceptance flow
• Auto-reconciliation of online orders to POS settlements — finance teams close from one number
• White-label ordering pages with custom branding, menu controls, and outlet-level configuration

Contactless ordering, table-side payment, and live menus — the guest experience improved, the service pressure reduced.

Dine-in technology often gets implemented as a novelty. I built it to solve a real operational bottleneck: the dependency on staff for order-taking and payment during peak hours was limiting table turn. I designed the QR menu and pay-at-table flow to move those steps off the critical service path — not to replace staff, but to free them for work that requires human judgment.

• QR menu with real-time availability, item photos, and dietary filters — menu reflects POS stock status with no manual update
• Table-side ordering: guests place orders directly to POS and kitchen with no staff intermediation needed
• Pay-at-table: guests initiate and complete payment from the table — no waiting for the bill, no separate payment terminal required
• Table turn time improved 19% at pilot outlets — billing and payment removed from the critical service path
• 2M+ sessions per month across the platform — all dine-in orders appear in POS and KOT identically to counter orders

Centralised control for restaurant groups — 20 to 200 outlets — without sacrificing outlet-level flexibility.

The challenge with multi-brand and franchise operators is that they need central control without losing local flexibility. A brand manager needs to push a price change across all 150 outlets instantly. An outlet manager needs to mark an item out of stock in the next 30 seconds. I built a hierarchical platform that handles both — config inheritance from brand to outlet, with granular overrides at each level based on role.

• Org → brand → outlet → channel hierarchy with role-based access control and config inheritance at every level
• New outlet activation from 3 days to 4 hours — remote provisioning with no site visit required
• Menu and config changes propagate to all outlets in under 90 seconds from the brand control panel
• Outlet-level overrides for local availability without breaking chain-wide pricing or menu rules
• Consolidated sales, operations, and settlement reporting across the full portfolio — one dashboard for groups managing 200 locations

Third-party integrations as a repeatable product — not a custom engineering engagement per partner.

Before the integration platform, every new aggregator or third-party system required a bespoke engineering effort — custom data mapping, manual testing, no sandbox, 6-week timelines. I rebuilt this as a product: versioned APIs, webhooks with delivery guarantees, a sandbox environment mirroring production, and a documented partner onboarding process. Integrations became a scalable capability, not an ongoing cost.

• Aggregator integrations: Swiggy, Zomato, and other delivery platforms — real-time menu sync and automatic order injection into POS
• Versioned REST APIs and webhooks for external systems connecting to POS and catalog data
• Sandbox environment mirroring production — partner integration onboarding from 6 weeks to 9 days
• Event-driven order routing: aggregator orders auto-accepted and injected into POS/KOT without manual steps
• Signed payloads, retry with backoff, and delivery guarantees on all order and menu events — 40+ active integrations

Service boundaries and shared foundations — 12 product lines that deploy independently without cascading each other.

The platform was a monolith when I joined — changes to the billing module required re-testing the catalog, a payment failure could bring down order acceptance, and every new capability required coordinating multiple teams. I defined the domain service decomposition: six independently deployable services with explicit API contracts, an event-driven backbone for cross-domain communication, and idempotent financial paths that are correct under retries and failures.

• Domain boundaries: POS, catalog, ordering, merchant, finance, devices — each independently deployable with versioned contracts
• Event-driven backbone enabling decoupled communication across domains without direct service dependencies
• Idempotent, auditable handling on all financial paths — correct under retries, partial failures, and concurrent writes
• Platform uptime improved to 99.7%; cascading failure rate reduced 82% — a payment service issue no longer takes down order acceptance
• New product capability build time reduced 40% — teams work on stable foundations without coordination overhead

Automated GST compliance built into the POS — not a separate tool merchants have to reconcile manually.

GST compliance for restaurants in India is genuinely complex: multiple tax slabs, composite schemes, HSN code requirements, and GSTR filing obligations. Before this product, compliance was a monthly manual process. I built it into the POS itself — so every transaction captures the right tax data automatically, and GSTR reports generate directly from that data without manual consolidation.

• HSN code library with automated mapping for 95%+ of common restaurant items — covers the long tail that trips up manual classification
• Configurable tax rule engine: GST slabs, exemptions, and composite schemes by item, category, and outlet
• GSTR report generation directly from POS transaction data — no manual export, transformation, or consolidation
• Compliance error rate reduced 67% across 10,000+ merchants after rollout
• Full audit trail: merchants can trace every tax line from transaction to GSTR return — useful for both internal review and GST notice responses

Every rupee traceable from transaction to bank account — settlement, reconciliation, and payout visibility in one layer.

Merchant finance anxiety is almost never about the total amount — it's about not knowing when money will arrive, why a settlement was short, or which transactions didn't reconcile. I built the finance enablement layer as a trust product: the primary goal was making every rupee's journey visible and traceable, not just accurate.

• Settlement engine with full audit trail per cycle: fees, refunds, adjustments, and tax deductions all visible in one view
• Reconciliation engine matching POS transactions to bank and PSP settlements — auto-resolved 89% of exceptions without manual investigation
• Merchant-facing financial reporting with transaction-to-payout traceability and CSV export for accounting teams
• Settlement support tickets reduced 41% after redesigning reporting around 'what settled today and why'
• Payout visibility dashboard: real-time settlement status, pending amounts, and exception alerts — merchants don't need to call support to know where their money is

UPI, QR, and EDC acceptance across the restaurant ecosystem — reliability at the counter, not the developer console.

Payment infrastructure in restaurants is not a fintech problem — it's an operational reliability problem. A failed payment at checkout during a lunch rush is a service failure, not just a transaction failure. I built payment acceptance as a component within the broader restaurant tech stack: UPI, QR, and EDC channels with reliability engineering at the centre.

• UPI success rate optimised to 97.4% (+4.3 pp) through health-aware payment routing and automatic retry logic
• QR payment integration across POS, dine-in, and online ordering — under 2s confirmation, 94% auto-reconciliation
• EDC terminal integration across 8,500+ terminals with offline-first transaction handling
• Payment gateway orchestration, settlement, and reconciliation integrated into the finance layer — not a separate system