Arabic-first software is a workflow decision, not a translation task

An interface can display Arabic correctly and still make the user work around the software.

Right-to-left layout is one visible part of Arabic-first product design. The less visible work is understanding the sequence of tasks, the roles involved, the device in someone’s hand, and the decisions that must be clear at the end of the day.

I learned this while building a custom operating system for a salon. The deployment was real and used by the owner and staff. It is now dormant, so this is a story about product decisions and what I learned from them, not a claim about current use or business results.

Translation changes words. Workflow changes the product.

Starting with English and translating later tends to leave the original product model intact. Arabic text is inserted into controls, but the way people move through the task may still reflect assumptions made for another language, device, or role.

The practical review goes beyond whether text reads right to left:

• Do forward and back controls point in the expected direction?
• Does the most common task fit a phone screen and thumb reach?
• Can staff complete a sale without navigating through owner-only controls?
• Are money, time, names, and status labels understandable in the order they appear?
• Does the screen make the next handoff clear when one person finishes and another takes over?

These are not regional stereotypes. They are questions to test with the people using the system.

Start with a workday, not a feature list

For the salon system, the core sale crossed a few roles and decisions: choose services, assign the worker, select how the customer pays, and confirm the transaction. That flow shaped the first product slice. Owner visibility into cash close and staff commissions followed the operating decisions the owner needed to make.

This is why I prefer to map one complete working path before writing a long feature list. A product can have many pages and still leave the key handoff unclear. A smaller system that carries one task from beginning to end may be more useful.

Roles are part of the interface

The same screen is not right for every person. A staff member needs the steps to serve a customer and see relevant earnings. A manager may need refunds or reports. An owner needs broader financial and staff visibility.

Separating those views changes the interface and the security model together. Hiding a button is not enough if the server still accepts an action from the wrong role. The permission decision needs to be enforced where data changes, then reflected in what each person can see.

The owner’s feedback also exposed a specific configuration blocker. We changed that narrow interaction and checked the change with the owner. That is a useful product result, but it is not evidence of a quantified increase in revenue, retention, or staff productivity.

Build for the conditions people actually have

In a phone-first operation, connectivity and device constraints belong in the product conversation early. If a network drop interrupts a sale, adding a more polished dashboard will not repair that moment. If a worker cannot tell whether a payment registered, a faster screen can make the underlying uncertainty worse.

The design questions should follow the work:

1. Where does the task begin?
2. Who takes each step?
3. What must remain accurate when the network or device is unreliable?
4. What does the next person need to know?
5. How will the owner know the process completed correctly?

The regional thesis still needs customer evidence

I believe custom, Arabic-aware operational software can be valuable to businesses across MENA. That is a direction to test, not proof that every business in the region has the same needs. The implementation should start with the individual company, its staff, and its current tools.

If you run a team in MENA, tell me where your staff currently switch between paper, WhatsApp, spreadsheets, and software to finish one important task. I build around that specific path, then check the result with the people who use it.