Bilingual and Offline-First: What We Learned Building Software for Egyptian Businesses

Most software is designed somewhere with fast internet, one language and a laptop on every desk. A lot of businesses in Egypt don't work like that. Across the systems we've shipped, including Brand+, a point-of-sale system for a fashion store at Porto Golf, New Alamein, and 3qar.co, our own real estate platform, the same three lessons keep coming back.

1. Bilingual means designed for both, not translated into one

Customers, staff and owners switch between Arabic and English all day. A system that treats Arabic as a translation layer on top of an English design breaks in small ways that add up: text that overflows its box, tables that read in the wrong direction, numbers and names that flip around in the middle of a sentence.

Brand+ runs in Arabic and English with a full right-to-left layout, because the people using it at the register work in both. 3qar.co is a bilingual marketplace with an Arabic name, عقارك, right next to the English one. In both cases, right-to-left was part of the design from the first screen, not a setting someone remembered at the end.

The Brand+ register screen, built for Arabic and English from the start.

2. If it runs a counter, it can't depend on the internet

A store can't stop selling because the connection drops. So Brand+ doesn't need one. The database, the API and the interface all run on a computer in the store, packaged as a desktop app installed from a USB drive. No internet needed to make a sale, and no monthly hosting bill for a single shop.

Not everything should work that way. A marketplace like 3qar.co is online by nature, because buyers and renters find it from their phones. The lesson isn't "always go offline", it's to ask early where the system actually runs, and what happens to the business in the minutes when the internet isn't there.

3. The hardware on the counter is part of the system

Nobody asks a software studio about receipt printers. But in Brand+, getting the system to talk reliably to a thermal receipt printer, printing straight through with no popup dialog in the cashier's way, took more real engineering time than the dashboard did. A great dashboard doesn't matter if the receipt won't print while a customer is waiting.

Printers, barcode scanners, cash drawers: if your business uses them, they belong in the plan from the start, not in a support ticket after launch.

What this means if you're planning a system

Before anyone picks a framework, it's worth answering three plain questions. Which languages do the people using it actually work in? What happens when the internet drops? What physical devices does it have to talk to? The answers decide more about the system than any feature list does.

Good software for an Egyptian business isn't a foreign product with Arabic added. It's built around how the business actually runs.