Offline-first point-of-sale system · Mobile · Offline-first · Retail
Pratika POS
Offline-first Android point-of-sale for retail, mini-markets and pharmacies in Angola.
- Role
- Founder & Software Engineer — product, architecture, mobile app, backend/sync, billing workflow
- Organisation
- Pratika
- Period · status
- 2026 · Completed
- Flutter
- Dart
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- Deno
Overview
Pratika POS is an Android point-of-sale that lets a small shop, canteen, mini-market or pharmacy run sales, stock and cash control from a single phone — and keep working when the internet does not.
It ships as a native Android app (Android 8+) with a companion website, a subscription model priced in Kwanza and a 15-day trial.
Problem
Small retailers in Angola operate with intermittent connectivity, mixed payment methods (cash, TPA card terminals, bank transfers, customer credit) and, in pharmacies, batch and expiry tracking. Cloud-only POS software fails the moment the network drops, and card-only billing excludes most of these businesses.
The product had to work offline by default, be operated by non-technical staff, print receipts on cheap Bluetooth printers and be paid for through local bank transfer rather than card.
Role
I defined the product, designed the architecture and built the app, the website and the backend/sync layer.
I also designed the account and subscription flow used across Pratika products, including bank-transfer payment with in-app proof-of-payment verification.
Architecture
- Flutter app on the device, chosen for its printer and hardware integration story; all operational data lives locally so checkout, stock and cash workflows never depend on a server round-trip.
- Synchronisation to the backend when connectivity returns. Backend on Supabase: PostgreSQL as the system of record and Deno functions for server-side logic.
- Next.js website for the public product site and downloads.
Technical decisions
- Flutter instead of React Native
- The deciding factor was hardware: Bluetooth receipt printers and camera barcode scanning had a more reliable path in Flutter for this project, so it was picked over my default mobile stack.
- Local-first data model
- Sales, stock movements, cash-register sessions and receipts are written locally first and synchronised later, so the app is fully usable with no network and reconciles when it is back.
- Bank transfer instead of card billing
- Subscriptions are paid by bank transfer and confirmed by uploading proof of payment inside the app, then verified — matching how Angolan small businesses actually pay.
- Per-operator cash control
- Cash-register opening with an initial float, withdrawals/deposits and closing with reconciliation are tracked per employee account, which is what makes multi-user shops auditable.
Stack
- Flutter
- Dart
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- Deno
Engineering challenges
- Keeping stock, batch/expiry and cash state consistent across offline sessions and later synchronisation.
- Camera barcode scanning and Bluetooth printing across a wide range of low-cost Android devices.
- Designing warehouse workflows (entries, movements with reasons, low-stock alerts, batches) that are auditable yet fast enough for a checkout queue.
- A voice assistant for registering merchandise and catalogue entries, so staff can add products without typing on a phone keyboard.
Outcome
Launched: Android app available for download at pos.pratika.io with retail and pharmacy operating models, multi-user employee accounts, receipts via Bluetooth or digital sharing, daily dashboards and period reports, CSV import and subscription plans in Kwanza.
What I learned
- Offline-first is a product decision before it is a technical one: it shapes the data model, the billing model and the support model.
- Hardware integration risk is worth deciding the mobile framework on, even when it means leaving a familiar stack.