DRW Skincare POS
The till a thousand beauty consultants ring sales through every day, on Android, iOS and the web, from one Flutter codebase.
- daily users across Android, iOS and web
- ~1,000
- Built for
- DRW Skincare
The problem
Roughly a thousand independent consultants were selling the same catalogue at different prices, because each one sits at a different tier in the distribution network, and reconciling that by hand at the end of a month is not reconciliation, it is archaeology.
An earlier attempt ran an offline-first sync layer. In practice it produced the worst possible failure: a sale that looked saved on the phone, and was not in the books. A cashier cannot be asked to know which of those two is true.
The approach
We took the offline layer out. The app is fully online and writes straight to the platform; the local database is a cache of the current session, never a second source of truth. When the network is down the app says so, which is a far better answer than a receipt that may or may not exist.
Pricing resolves in exactly one place on the server. A consultant''s tier decides the price, promotions apply on top under rules the server owns, and the client is never trusted with the total — it sends the basket, the server answers with the amount. Every write carries an idempotency key, so a retry over a flaky connection cannot mint a second order.
The same codebase produces the Android build on Google Play, the Huawei AppGallery build, the iOS build for TestFlight, and the web cashier — with thermal-printer receipts, barcode scanning, per-consultant stock, deposits and receivables, and a loyalty wallet on top.
The outcome
In production and used every working day by around a thousand people, on three platforms and two Android app stores.
Prices agree with the ledger because they are computed in one place, and a dropped connection now produces an error the cashier can act on instead of a sale nobody can find.