Designing for two markets: how AcademicGrid runs in India and UAE on a single codebase
AcademicGrid started in India. When we expanded to the UAE and GCC, we faced a decision: build separate codebases for each region, or design one system flexible enough to handle both.
We chose one codebase with regional configuration. That decision shaped everything—database connections, curriculum frameworks, compliance rules, even UI text.
The problem: India and UAE are not the same
On the surface, both are schools with students, teachers, and fees. But the details diverge significantly.
**Curriculum structures** vary dramatically. In India, schools follow CBSE, ICSE, or state board curricula. In the UAE, schools follow British, American, or IB curricula.
**Academic calendars** differ. Indian schools run June-April. UAE schools run August-July.
**Fee structures** are different. India uses rupees and installments. UAE uses AED and lump sums.
**Compliance & data residency** matter. India requires data localization. The UAE has GDPR-like regulations.
**Language & localization** vary. India may use English, Hindi, or regional languages. The UAE uses English and Arabic.
Our approach: configuration-driven behavior
Instead of branching on region in business logic, we built a **configuration layer** that owns all regional differences.
When a school is created, it's assigned a region. Every feature from that point on reads the region configuration. The application doesn't know about Indian vs. UAE differences—it only knows about "the configured academic calendar for this region."
Curriculum frameworks: from configuration to UI
Schools in different regions teach different curricula. We modeled this as a flexible framework where a school chooses its curriculum framework (CBSE, British, American, IB), and the UI automatically adjusts.
Data residency: hard boundaries
Data residency isn't a nice-to-have—it's a legal requirement. Indian data must stay in India. UAE data must stay on EU-compliant servers.
We solved this at the connection level with database routing per school based on region.
Compliance and audit rules
Different regions have different compliance requirements. We modeled this as pluggable rules that enforce compliance without scattering code.
Localization: more than translation
Language is part of localization, but so is date formatting, number formatting, and regional terminology. All configured per region.
The result: one codebase, two markets
With configuration driving behavior, we ship the same code to production for both regions. Updates roll out instantly to every school.
What we learned
1. **Configuration gets complex fast.** Version control and documentation are critical. 2. **Configuration is still code.** Someone needs to own and test regional configs. 3. **Not everything can be configured.** Some differences are too fundamental. 4. **Different regions need different support teams.** Configuration unlocks one codebase, but compliance still needs expertise.
For your multi-region product
If you're building for multiple markets:
- **Invest in a configuration layer early.** Don't hardcode for the first market.
- **Version your configurations.** You'll need to roll back configs just like code.
- **Document regional differences.** A spreadsheet of differences is invaluable.
- **Test regionally.** A test that passes in India might fail in the UAE.
---
*If you're building for multiple regions, contact us at [email protected].*