Erin Rai
← All work
Commerce, 2026

Ottr Omni-Ledger — branch-based commerce platform

E-commerce, retail POS, restaurant POS and mobile from one codebase, on an append-only inventory ledger with seven payment providers.

Role
Architect and lead developer
Context
Own product, Ottr Technology
Scale
774 commits, ~2,300 source files, ~100 Prisma models, 9 apps, 8 services, Jan – Sep 2026
Live
storefront.ottr.com.np
Storefront catalogue with filters
Storefront: all products with category and price filters.

Background

A single platform for a business that sells through a web store, a shop counter and a restaurant floor at the same time. One organisation, many branches and warehouses, one stock truth. It ships as a multi-org admin, a storefront, an Electron POS for retail, a restaurant POS with QR-scan customer ordering, Flutter apps for customers and waiters, and an AI marketing studio.

I built all of it, from the Prisma schema to the thermal-receipt printing. It is the largest system I have built.

Screens

Restaurant POS table order screen
Restaurant POS: table order with menu grid and a fire / settle ticket panel.
Kitchen display ticket queue
Kitchen display: live ticket queue driven by the same order events.

The problem

Nepali SMBs run e-commerce, retail and restaurant from separate tools that disagree about stock, and pay through local gateways that no global platform supports. Stock in particular has to survive concurrent sales from a website, a counter and a kitchen, offline POS terminals that sync later, and the audit questions that follow.

The second constraint was deployment. One client might want only the storefront, another only POS. The system had to run as a subset without forks.

Approach

  1. Make inventory an append-only ledger. Every movement is a row: RECEIVE, SALE, TRANSFER_IN and TRANSFER_OUT, ADJUSTMENT with a mandatory reason, RESERVE and RELEASE that move on-hand to reserved with no net change, and WASTAGE. Quantities are Decimal(12,4) so kilograms and metres work. Levels are derived, never edited.
  2. Put payments in a Go gRPC service with a provider interface: Stripe, eSewa, Khalti, Fonepay and ConnectIPS, PayPal, Razorpay and manual. Config is per organisation. The POS handles cash with change, QR payments with two-second polling and auto-confirm, card terminal and split tender.
  3. Multi-tenancy as Organisation, Member, Branch and Warehouse, with Super Admin, Org Admin and Shop Admin roles, and per-org subdomains for store, admin and POS.
  4. Split the API into three NestJS entry points (admin, e-commerce, POS) on one schema, with Go services for inventory, payments and MeiliSearch-backed search, and RabbitMQ and BullMQ between them.
  5. Offline-first POS on Electron: SQLite product cache, an order queue that syncs when the network returns, USB HID barcode scanning, silent 80 mm thermal printing, two-step login with branch selection.
  6. Docker Compose profiles (dev-full, dev-ecommerce, dev-pos, dev-admin) and live module control in the admin panel so a deployment runs only what the client bought.
  7. AI on the edges: a Rust chatbot service per storefront (works with Ollama) and a marketing studio for campaigns, audiences, brand kit, copy, image and video, calendar, coupons, affiliates and approvals.
  8. Operations as a first-class module: Prometheus, Grafana, Loki, Promtail and blackbox exporter; Caddy edge with nginx; Swagger per API; Playwright end to end; commitlint.

Architecture

sync queueStorefrontNext.jsRetail / Restaurant POSElectron + SQLiteMobile appsFlutterAdminNext.jsNestJS APIadmin · ecommerce · posinventory-serviceGo gRPCpayment-serviceGo gRPC · 7 providerssearch-serviceGo + MeiliSearchPostgreSQL 16InventoryLedger (append-only)RabbitMQ · BullMQevents, jobs
Omni-Ledger: three NestJS entry points and three Go services share one Postgres schema; every stock change is a ledger row.
apps/admin, apps/ecommerceNext.js 16, React 19, Tailwind 4.
apps/pos, apps/restaurant-pos, apps/restaurant-customerElectron 33 + React + SQLite; QR-scan ordering.
apps/mobile, apps/restaurant-mobileFlutter customer and waiter apps.
services/nestjsThree entry points on ~100 Prisma models, PostgreSQL 16.
services/goinventory-service, payment-service, search-service. Gin + gRPC + pgx.
services/chatbot-rs, ai-builder-service, marketingRust axum chatbot, Python FastAPI builder, NestJS marketing.
packages/proto, shared-typesProtobuf contracts and shared TypeScript types.

Outcome

  • Storefront, admin and edge deployed under ottr.com.np subdomains with staging and production compose files, and an ops deployment log.
  • Still active: the last commit is from the day this site was built.
  • The ledger, payment and tenancy patterns were reused in Ottr Kiln and GC LAL.

Lessons

  • An append-only ledger costs nothing extra to write and answers every 'why is stock wrong' question later. Derived levels with a daily stat table keep reads fast.
  • Reserve and release as explicit movements, not a flag, is what made online checkout and counter sales coexist.
  • Five languages in one monorepo is defensible only with go.work, Turborepo and protobuf contracts. Without those it would have collapsed.

Stack

TypeScriptGoRustPythonDartNestJSPrismaPostgreSQLgRPCNext.jsElectronFlutterMeiliSearchRabbitMQBullMQMinIOTurborepo