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 by institution. Frameworks include CBSE, ICSE, state boards, British, American, and IB curricula.
Academic calendars differ by institution and curriculum.
Fee structures vary by currency, payment schedule, and institution.
Compliance & data residency requirements vary by jurisdiction, institution, and data type.
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 requirements need to be confirmed for each institution before choosing a hosting region.
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
- Configuration gets complex fast. Version control and documentation are critical.
- Configuration is still code. Someone needs to own and test regional configs.
- Not everything can be configured. Some differences are too fundamental.
- 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 contact@heaplex.com.