Build Arabic-first products that feel native to users across the Gulf and MENA — not English interfaces with translated labels.
softodeviq helps SaaS teams, ecommerce companies, agencies, and product owners design, localize, and engineer Arabic RTL experiences across onboarding, dashboards, forms, checkout, mobile interfaces, and business workflows.
Working with teams targeting the UAE, Saudi Arabia, Qatar, Kuwait, Iraq, and the wider MENA region — delivered remotely from our engineering base in Baghdad.
Over a decade of delivery experience across web, mobile, and business systems.
Businesses and product owners who trusted softodeviq to build and ship their software.
Using Madrasati Plus, the Arabic-first school platform developed by softodeviq.
Arabic-first products shipped for organizations in Iraq and Gulf markets.
Three different disciplines get sold under one word. Buying the wrong one is the most expensive mistake teams make entering Arabic markets:
| Translation | Software localization | RTL engineering |
|---|---|---|
| Changes language | Adapts product content and behavior | Corrects interface and architecture |
| Text-focused | Context and workflow-focused | Code and component-focused |
| May use translators | Requires product context | Requires engineers and QA |
| Does not fix layout | Includes linguistic QA | Handles direction, bidi, forms and UI |
Translation alone does not fix RTL. RTL engineering alone does not produce high-quality Arabic wording. A strong Arabic product usually requires both linguistic and engineering work — sequenced correctly.
Where does product wording come from? Translation can be coordinated as a separate project workstream, or we integrate client-provided Arabic translations and flag content that requires professional linguistic review — while softodeviq owns the product integration, context, RTL implementation, and in-product QA. softodeviq does not provide certified, sworn, legal, or medical document translation.
These are the failure patterns we correct most often when an English product meets Arabic users. If several rows sound familiar, run the free readiness self-assessment or the full RTL testing checklist.
| English interface symptom | Arabic/RTL failure | User impact | Engineering correction |
|---|---|---|---|
| Back arrow at the top of every screen | Still points left — which now means “forward” | Users navigate backwards by accident | Mirror directional icons via a curated icon rule set, not a global flip |
| Phone and OTP inputs | Digits type right-to-left and cursor jumps | Sign-in and verification fail — a launch blocker | Force dir="ltr" on numeric/technical fields inside the RTL form |
| Product codes like INV-2024/003 in Arabic sentences | Segments reorder around the hyphens and slashes | Invoices and references become unreliable | Wrap codes in <bdi> or dir="ltr" spans (bidi isolation) |
| Checkout address form | Street/ZIP order that Gulf buyers don't use | Half-empty addresses, failed deliveries, abandoned carts | Restructure to market format: governorate, district, landmark |
| Data tables | Identity column stranded on the far left | Operators scan every row twice | Reorder columns for RTL reading; fix a numeric-alignment rule |
| Charts and legends | Axes and legends keep LTR assumptions | Dashboards mislead at a glance | Configure per-library RTL: axis direction, legend side, tooltip anchor |
| PDF invoices and emails | Render LTR even when the app is RTL | The most-forwarded artifacts look broken | Build dedicated RTL templates — app-shell CSS never reaches them |
| Long Arabic button labels | Overflow or clip mid-word | Primary actions look broken exactly where trust matters | Set wrapping/width rules sized for Arabic label lengths |
| Validation messages | Appear on the wrong side of the field | Users miss errors and resubmit blindly | Anchor messages with logical properties, verified per breakpoint |
| Prices like “(100 IQD)” mid-sentence | Parentheses and units flip order | Totals read ambiguously — poison for checkout trust | Isolate number+unit pairs and set explicit direction per fragment |
Translating strings is the smallest part of shipping an Arabic product. The work that decides whether the product feels native happens in layout architecture, typography, bidirectional text, and every flow a user touches. These are the areas we engineer:
RTL is a layout mode, not a CSS patch. We build with logical properties (start/end, margin-inline, padding-inline) and direction-aware components so the same codebase renders correctly in both directions without per-page overrides.
Arabic script needs proper font selection, line-height, letter connection, and diacritic handling. Latin-optimized type scales usually break Arabic readability, so weights and sizes have to be re-tuned.
Real products mix Arabic text with English product names, codes, and emails. Bidirectional text needs explicit isolation (dir attributes, bdi, unicode-bidi) or numbers and brackets render in the wrong order.
Menus, breadcrumbs, back buttons, carousels, steppers, and directional icons (arrows, chevrons) must mirror. Some icons mirror and some must not — a rule set, not a global flip.
Field alignment, label position, placeholder direction, error message placement, and input types (phone numbers stay LTR inside an RTL form) all need deliberate handling.
Column order, sort indicators, sticky columns, pagination controls, and cell alignment flip in RTL. Numeric columns often stay LTR-aligned for scanability.
Axis direction, legend placement, tooltip alignment, and time-series orientation need review per chart library — most charting defaults assume LTR.
Hijri vs Gregorian expectations, Arabic-Indic vs Latin digits, currency symbol placement (IQD, SAR, AED, QAR, KWD), and address formats differ by market and must be consistent across UI, exports, and messages.
Cart, address, payment, and confirmation steps are where broken RTL costs revenue. Card fields, OTP inputs, and gateway-hosted pages need mixed-direction handling and market-appropriate payment options.
RTL bugs multiply on small screens: swipe direction, drawer position, truncation, and keyboard behavior for Arabic input all need device-level QA.
Transactional emails, PDFs, invoices, and push notifications are rendered outside your app shell and are commonly forgotten — they need their own RTL templates.
Screen-reader language tagging, focus order in mirrored layouts, and readable contrast with Arabic type sizes keep the product usable for everyone.
hreflang, canonicals, localized titles and descriptions, structured data in the right language, and a URL strategy that will not fragment your search equity.
Product teams adding Arabic as a first-class locale: onboarding, billing, dashboards, and settings that behave natively in RTL.
Stores that need Arabic catalogs, RTL checkout, local currency and address formats, and market-appropriate payment and delivery flows.
Design and development agencies that need a reliable RTL engineering partner behind their own client work.
Learning platforms and school systems where Arabic content, grading, timetables, and parent communication are core — the domain where we built Madrasati Plus.
Listing portals and property websites serving Arabic-speaking buyers, with bilingual listings, maps, and inquiry flows.
Appointment, clinic, and service-booking products where Arabic forms, reminders, and patient-facing documents must be exact.
Back-office systems where Arabic-speaking staff work all day: data tables, reports, permissions, and printing in RTL.
Teams with a working English product that needs a structured RTL retrofit instead of a rewrite.
The stack matters less than how it is used for direction, locale, and Arabic content. This is how our tooling supports Arabic-first products:
We work in Next.js, React, TypeScript, and JavaScript daily, and build RTL design systems on logical CSS properties so components render correctly in Arabic and English from one codebase. React Native carries the same approach to iOS and Android, where RTL gestures and navigation need native-level care.
Node.js, Python, and Django services with PostgreSQL and REST APIs, structured for localization from the data model up: translatable content fields, locale-aware formatting for dates, numbers, and currencies, and message templates that render correctly in both directions.
Admin panels, reporting dashboards, and payment and delivery workflows are where Arabic-speaking teams spend their day. We build data tables, charts, exports, and receipts that hold up in RTL under real operational load.
Responsive UI and accessibility reviews across devices, plus structured data and technical SEO — hreflang, canonicals, and localized metadata — so Arabic pages are indexable and legible to both search engines and AI systems.
The clearest evidence is shipped work: Madrasati Plus runs Arabic-first — timetables, grading, attendance, and parent messaging built RTL-native from day one for 10,000+ active students — and our completed Doha real-estate delivery required bilingual listings with mixed Arabic/English property data. The panels below are purpose-built demonstrations of the same techniques, not client screenshots.
/* breaks in RTL */
.card { margin-left: 16px; text-align: left; }
/* works in both directions */
.card { margin-inline-start: 16px; text-align: start; }<p dir="rtl">
رقم الفاتورة <bdi>INV-2024/003</bdi> جاهز
</p>
<input dir="ltr" inputMode="numeric" name="otp" />new Intl.NumberFormat("ar-IQ", {
style: "currency", currency: "IQD",
}).format(250000);
new Intl.DateTimeFormat("ar-IQ", { dateStyle: "long" })
.format(orderDate);softodeviq was founded by Sami in 2013 and is trusted by more than 300 clients. We developed Madrasati Plus, an Arabic-first school management platform used by more than 10,000 active students and serving schools in Iraq and Gulf markets. Our regional delivery experience also includes a completed real estate website project for a client in Doha, Qatar.
See case studiesEngagements are scoped to your product and stage — from a readiness audit to full Arabic-first development. Pricing follows scope, not a fixed menu.
We walk through your product, target markets, and current localization state to define scope.
Structured review of layout, components, flows, content, and architecture in RTL.
Prioritized plan: blocking issues, quick wins, and the sequence that gets you to launch.
Engineering work with desktop and mobile QA, mixed-language testing, Arabic content testing, browser testing, and form and checkout validation.
Release support, post-launch monitoring, and iteration as real Arabic-speaking users hit the product.
We sign your NDA before receiving access — standard for pre-launch products and internal systems.
We prefer staging environments with revocable test accounts over production access.
Access is requested per role and flow in scope — never broader than the engagement needs.
At completion we ask you to revoke supplied credentials and access; nothing persists on our side beyond the deliverables.
Start with a practical audit of what will break in RTL — then fix it with a team that builds Arabic-first products for a living.