OPAALA VENUES
Kitchen admin panel for OPAALA — the venue-side of a contactless hospitality platform used by restaurants, hotels, and cinemas across the UAE. Real-time KDS, KOT printing, multi-printer zone management. Shipped 2020, still shipping in 2026.
THE WORK
// 01 · PROBLEM · APPROACH · OUTCOMEHospitality printing is where good apps go to die.
Restaurants run on receipts, KOTs, and zone-specific tickets — kitchen, bar, expo, prep. Each station has its own printer. Each printer has its own quirks: Bluetooth pairing, ESC/POS dialects, charset mismatches, paper-out states that lie. Get any of it wrong and the kitchen stops working.
Opaala needed an iPad-first venue console that handled all of that without operators thinking about it — and kept handling it through five years of new hardware, new venues, and new printer SKUs.
Printing as an engine, not a feature.
Built the kitchen admin panel in Flutter — single iPad codebase, multi-venue, multi-zone. Pulled the printing layer out into its own engine with a clean public surface: register a printer, bind it to a zone, send formatted tickets. The engine handles transport (Bluetooth + WiFi), dialect (ESC/POS variations), and recovery (paper-out, disconnect, queue retry) behind a single API.
That engine became fifty_printing_engine — published to pub.dev so the same patterns ship to every Fifty client who needs receipts, tickets, or labels. Opaala was the first production deployment; the package is its public extraction.
Live since 2020. v2.27.1 in 2026. Same engine throughout.
Opaala Venues launched on the App Store in 2020 and reached v2.27.x by early 2026 — five-plus years of continuous shipping. Used by venues including Zabeel House by Jumeirah and other UAE hospitality properties. KDS, KOT printing, multi-zone management all in production.
The printing layer hardened by venue feedback became fifty_printing_engine, now an independent open-source package powering hospitality and retail clients beyond Opaala.
ARCHITECTURE
// 02 · LOOP DIAGRAMforthcoming
STACK
// 03· WHAT IT'S MADE OFPROCESS
// 04 · BEFORE → AFTERNUMBERS
// 05 · WHAT SHIPPEDLESSONS
// 06 · WHAT TO TAKE FORWARDHardware in production teaches what tutorials can't.
ESC/POS is a swamp of vendor variants. Each printer's actual behaviour only emerges after a year in real kitchens — paper-out lies, Bluetooth reconnect quirks, charset mismatches. The engine got hardened venue by venue.
Zones over devices.
Operators don't think 'printer X' — they think 'send this to the bar.' The engine binds printers to zones. Replace a printer, rebind the zone, no app changes. Five years of swap-outs handled this way.
Extract the engine when it stabilises.
Opaala carried the printing layer for years before it became fifty_printing_engine. Extraction isn't free — you do it when the surface is stable enough that downstream clients won't pay for the churn. Then everyone benefits.
Hospitality apps live or die at the printer.
If the kitchen ticket doesn't print, service stops. Everything else in the app is secondary. Engineering attention should match that reality — printing got more iterations than any other surface.
HOSPITALITY OR RETAIL APP?
iPad-first ops apps with battle-tested ESC/POS printing — KDS, KOTs, receipts, labels. Multi-zone, multi-printer, hardened by five years of Opaala in production.