OPSARA
Friday night rush at a Lagos restaurant. The network drops — again — and the point-of-sale screen freezes on a spinner while orders pile up at the pass. Staff fall back to paper and shouting. Global SaaS calls that an error state. For most Nigerian venues, it's just Tuesday.
OPSARA is an offline-first hospitality operating system for Nigerian and pan-African SME restaurants, bars, and hotels — built for venues where losing the network is part of a normal week.
POS floor plan with live table status, per-seat orders, and at-a-glance service metrics
Problem
African hospitality SMEs run a service on paper tickets, WhatsApp bookings, and disconnected point tools — because the software sold to them was never built for their infrastructure. Global SaaS assumes a live backend, so it fails exactly when the venue needs it most: mid-rush, mid-order, mid-payment. Every failure teaches operators to trust software a little less.
Solution
A unified hospitality OS — POS floor plan, kitchen display, bookings, inventory, and owner analytics — that treats offline as a normal operating mode rather than an error. A sync queue captures every action locally and drains on reconnect, so a dropped network never stops a service. A single state model serves four personas (cashier, server, kitchen, owner) and three property types (restaurant, hotel, bar).
Product Surface
POS Floor Plan
A spatial table grid with a Free, Seated, Active, Billing status progression. Each status shows only the actions that apply to it, and a right-rail detail pane keeps everything on one screen.
Kitchen Display (KDS)
A dark-themed back-of-house view appropriate for kitchen environments, creating clear product separation between front-of-house and the line.
Bookings & Inventory
A chronological reservation timeline with WhatsApp / phone / online channel chips and deposit tracking, plus an on-hand-vs-par stock view whose reorder basket auto-groups by supplier.
Owner Analytics
An owner persona with venue-level metrics, switchable across restaurant, hotel, and bar property types from a single state model.
Stock and suppliers view: on-hand vs par with a supplier-grouped reorder basket
Offline-First Sync
Most SaaS treats offline as an error. OPSARA treats it as a normal way to operate. A sync queue captures every action locally, then drains on reconnect with a visible animation and conflict-free toasts, modeling a real IndexedDB sync engine without any backend. This is the part operators running on Nigerian infrastructure respond to most.
Key Decisions
01Offline is the default, not the fallback
ConsideredThe standard play: build online-first, then bolt on a read-only cache for outages.
ChoseA local-first sync queue where every write — orders, payments, table state — commits locally first and drains to the network later. Caching reads doesn't save a service mid-rush; capturing writes does.
Trade-offReconciliation complexity moves into the app. The win: the floor never blocks on a spinner.
02One state model, four personas
ConsideredSeparate apps per role — cashier, server, kitchen, owner — each with a smaller, cleaner scope.
ChoseA single root state model with persona switching. In an SME venue the same person is often cashier at lunch and manager at close, so a state switch beats a re-login — and one source of truth means the floor and the kitchen can never drift apart.
Trade-offA heavier root model to design up front. The win: one codebase serving four contexts with zero duplication.
03A simulated sync engine before a real backend
ConsideredStanding up a real server and database first, then building the screens against it.
ChoseSimulating the IndexedDB-style sync engine in-browser and spending the time on operator-facing workflows instead. The risky assumption was never whether a backend could be built — it was whether offline-first workflows would hold up in a real service.
Trade-offSync conflicts are modeled rather than battle-tested. The win: module boundaries and a sync contract that translate directly to a Next.js + IndexedDB build.
Technology
Design Approach
OPSARA was designed from the operator outward, grounded in how Nigerian hospitality venues actually run a service rather than in software convention. The prototype was built alongside supporting product work: system design, a competitive read of the local market, and the workflow research that shaped each screen. Every interaction maps to a real operational need.
Outcome
Before
The network drops mid-rush: orders are lost, bills go wrong, and staff fall back to paper.
After
Every action is captured locally and reconciled on reconnect — the service never stops.
A polished prototype that holds its own against funded global hospitality SaaS on design quality — and proof of the offline-first thesis across the full path from problem discovery to interaction design to a working multi-persona build.
Founder's Note
OPSARA is my own venture — the project I'd be building even if nobody were hiring. Nigerian hospitality is run by some of the most resourceful operators anywhere, working around tools that were never built for their reality. Global software treats African infrastructure as an edge case; I think it's a market waiting for someone to take it seriously.
The prototype on this page is the first proof. The venture is the long game: a hospitality OS built for how this market actually works — offline first, operator first.
— Tolulope Babajide, Founder