Country registry
A shared registry models 22 Arab markets with ISO codes, Arabic and English names, calling codes, locales and currency metadata.
CASE STUDY · DEVELOPER INFRASTRUCTURE · OPEN SOURCE · 2026
ARABDEVKIT
Open-source developer infrastructure for software built for the Arab world — one consistent API for Arabic text, country metadata, phones, money, IBANs, validation, form primitives, test data and developer tooling.
VIEW SOURCE CODE ↗WHY I BUILT IT
Teams building for Arab markets repeatedly solve the same localization and validation problems in isolation.
Arabic text normalization, local phone input, currencies, address structures, IBAN rules, tax identifiers and realistic test data are common product requirements across the region. They are often reimplemented independently inside each application.
ArabDevKit turns that repeated work into shared infrastructure. The core package owns country-aware rules and metadata while framework-specific packages reuse the same logic for validation, React inputs, synthetic data and CLI workflows.
PACKAGE ARCHITECTURE
01CoreCountry + Arabic primitives
→02Zod / ReactValidation + UI primitives
→03Faker / CLITest data + developer tooling
→04ApplicationsReusable regional infrastructure
CORE SYSTEMS
Arabic text primitives
Normalization and Arabic-Indic digit conversion make Arabic input handling a first-class engineering concern instead of an afterthought.
Phone and money
Country-aware phone normalization and localized money formatting expose one consistent API across different markets.
IBAN support
The toolkit validates ISO 13616 structure, country BBAN formats and MOD-97 checks for supported Arab markets without claiming unsupported rules.
Framework packages
Core logic is separated from Zod schemas, React primitives, Faker data and CLI tooling so teams can adopt only what they need.
Provenance boundaries
Country-specific regulatory helpers are added only when backed by authoritative specifications, with unverified capabilities labeled explicitly.
DEVELOPER EXPERIENCE
01choose country
02normalize input
03validate
04render / format
05ship
The same country model powers formatting, validation, UI primitives, generated test data and CLI checks, reducing divergence between application layers.
TECHNICAL STACK
TypeScript · country registry · Arabic text · phone · money · IBAN
Zod · country-aware schemas · conservative capability states
React · unstyled accessible country, phone, IBAN and address primitives
CLI · seedable Faker · project readiness audit
pnpm monorepo · tests · CI · framework examples
ENGINEERING DECISIONS
One source of truth
Country metadata and capabilities live in the core package so React, Zod, Faker and CLI layers do not invent their own regional rules.
Verified, not guessed
Regulatory validators are implemented only when authoritative structure is available; unsupported or unverified states remain explicit.
Framework-independent core
Business rules stay outside React so server code, scripts, validation and UI packages can consume the same underlying primitives.
Arabic first-class
Unicode normalization, Arabic digits, bilingual metadata and RTL-oriented workflows are core features rather than optional localization patches.
WHAT THIS PROVES
The project is organized as reusable packages with clear responsibilities instead of application-specific helpers.
Arabic language behavior and country differences are modeled as software architecture concerns.
Capability states and authoritative-source boundaries prevent the library from presenting assumptions as verified rules.
Core APIs, schemas, UI primitives, Faker and CLI tooling are designed to work together across real project workflows.
NEXT CASE STUDYWORKGRID ↗