Talabatek
Arabic-first delivery, built for real POS hardware
A food and grocery delivery platform in Palestine with four Flutter clients: customer, driver, restaurant and web. 10K+ installs on Google Play.
- Country
Palestine- Type
- Client project
- Timeline
- 2024–2026
- Platforms
- Android · iOS · Web
- installs on Google Play
- 10K+
- Flutter clients
- 4
- unit tests
- ~80
- brands on one platform
- 3
Overview
Talabatek is a food and grocery delivery service in Palestine, covering Shu'fat Camp, Anata, Ramallah, Kafr 'Aqab, al-Ram, Nablus and the areas around them. Customers order from restaurants, cafés and grocery stores, drivers pick up and deliver, and restaurants run their menus and order boards from a dedicated app.
I was the lead Flutter engineer for every client app: customer, driver, restaurant with thermal receipt printing, and the Flutter web app. The customer app has been on the App Store since January 2024, and all four clients kept evolving through 2026, including a full dark and light redesign.
The challenge
- 01
Three audiences, three apps: customers need fast browsing and simple checkout, drivers need clear one-tap alerts on the move, and kitchen staff need a board readable from across the room.
- 02
Real hardware: restaurants run Sunmi and other Android POS terminals or Bluetooth printers, and receipts must print in Arabic with zero setup.
- 03
Flaky networks and aggressive Android task-killing: sessions, OTP flows and order alerts must survive process death.
- 04
City-based coverage: the backend models cities and areas by name, not coordinates, yet the phone still has to work out where the customer is.
- 05
Fast shipping: hot fixes go out over the air without waiting for a store review.
Highlights
Customer app
- Browse restaurants by category, search with Arabic text normalisation, and discover 'new' and 'free delivery' rails.
- Cart and checkout with cash on delivery, saved addresses and a map-based address picker.
- Order history, ratings and reviews, plus an active-order banner that refreshes in the background.
- OTP phone login, Google, Apple and Facebook sign-in, and verified App Links that open shops and orders directly.
- A short-video reels feed, in-app chat, and light and dark themes.
Driver app
- An 'orders radar' home screen with online/offline status and earnings counters.
- Persistent order notifications with Accept and Reject buttons, and critical alerts that ring even in silent mode.
- Weekly shift booking and a ratings and reviews screen.
Restaurant app
- A live order board grouped by stage: new, preparing, ready, on the way, done and rejected.
- Automatic thermal printing of every new order on Sunmi, built-in POS and Bluetooth printers.
- Menu management with images and per-item video, availability toggles and offers.
- A quick-order form to request a driver for orders the restaurant took itself, plus statements, notifications and dark mode.
Web app
- The customer experience ported to the browser with Flutter web, including a city picker, cart and OTP login.
- Clean-architecture features with
go_routerandhydrated_bloc. - Deployed as a static build behind nginx.
Signature feature
Orders that print themselves
- Restaurants don't want to tap print for every order, so the restaurant app prints each new order automatically on whatever printer the device has.
- Printer detection runs in order: a Sunmi device first, then the built-in Intelligent POS printer through a small Java
PrinterClientthat sends raw ESC/POS bytes over an AndroidLocalSocket, and finally a Bluetooth printer. - Receipts are laid out for 80 mm paper with
esc_pos_utils_plusand UTF-8 Arabic text; on Sunmi the native right-aligned text API is used. - No order prints twice: printed IDs persist across restarts (capped at 400), existing orders are marked printed after an update, orders older than 12 hours are skipped, and an order only counts as printed once paper comes out, with up to 3 attempts per session.
- It reacts fast: a 15-second refresh while the app is open, an instant refresh on a new-order push, and single-flight fetches so overlapping refreshes can't double-print.
Screens
Swipe for more
Engineering notes
- 01
Token refresh safe for rotating refresh tokens
All apps share one
SessionManagerwith a single-flight refresh, so concurrent 401s trigger only one refresh call. The new refresh token is saved before the access token, and only a real 401 logs the user out; a 429 or 503 is treated as temporary. - 02
Server-side OTP
OTP verification moved from the device to the server, and I documented the backend contract for the API team. Only the pending phone number is persisted, never the code, so Android killing the app mid-flow doesn't lose the user's place.
- 03
City matching without coordinates
The app reverse-geocodes the customer's location and fuzzy-matches it against city and area names, normalising Arabic spellings and mapping English geocoder names to Arabic. 13 unit tests cover it, including false-match cases.
- 04
Driver alerts that can't be missed
Order notifications stay on screen with Accept and Reject actions, an opt-in critical mode sounds through silent mode, and a heartbeat tells the backend which drivers are really online.
- 05
Four apps kept in step
Shared Arabic UX patterns and
TkDesigntokens let the dark v2 redesign ship across the customer, driver and restaurant apps in the same release cycle.
Results
- Customer app: 10K+ installs on Google Play, and on the App Store since January 2024.
- Driver app: 100+ installs on Google Play.
- Restaurant app: 100+ installs on Google Play, also on the App Store.
- 4 Flutter clients shipped, with about 80 unit tests and
flutter analyzeclean across all four projects. - The same platform was later redeployed for two more brands: OneWay Fast Food and Jahiz.
Stack
- Flutter
- Bloc / Cubit
- Dio
- Socket.IO
- FCM
- Crashlytics
- Google Maps
- flutter_map
- ESC/POS
- Sunmi SDK
- go_router
- hydrated_bloc
- Shorebird
- nginx