IMMAR

The defining decision in IMMAR was made before any interface was designed: students would get their own application, and the web dashboard would never be for them.

It is tempting to build one responsive web application and give every role a filtered view of it. That approach fails quickly here. A student on a mid-range Android phone opening a lesson has almost nothing in common with an administrator reconciling activation codes and settlements across multiple teachers. Their sessions differ, their security requirements differ, and their failure modes differ.

IMMAR is multi-teacher. A teacher owns their content and their students; teacher staff act on a teacher’s behalf within limits; administrators operate the platform across everyone. Getting that hierarchy wrong exposes one teacher’s material — or one teacher’s revenue — to another.

• The student application

  Built in Flutter and designed around a single question: what am I studying next? Content, assignments and assessments are reachable in as few taps as possible, and the app has to stay usable on an inconsistent mobile connection.

• The operational dashboard

  Designed for density and repetition. Teachers and staff work through long lists of students, submissions, attendance and codes, so the dashboard is optimised for scanning and bulk action rather than for a guided journey.

Arabic and English are treated as equal materials rather than a base language and a translation. Both directions were designed, not derived: the dashboard’s navigation, tables, date handling and form flow each have an authored RTL behaviour, and technical identifiers stay left-to-right inside Arabic screens.

The API is an ASP.NET Core 8 modular monolith with a strictly one-way dependency flow. Domain knows nothing about persistence or HTTP; Application holds services, DTOs, validators and provider ports; Infrastructure implements them; the API layer only composes. That constraint is what keeps a platform with this many modules from turning into a single tangled service.

• Challenge

  One account shared across a class defeats the entire commercial model of a paid education platform.

  Decision

  Device and session management binds an active session to a device, with administrative controls to reset it when a student legitimately changes phone.

  Trade-off

  Adds a support workflow — but the alternative is a platform teachers will not publish to.

• Challenge

  Permissions written as code checks scattered across controllers become impossible to audit.

  Decision

  Permissions, system roles and settings are seeded as catalogued data, so the access model can be read as a table instead of inferred from source.

  Trade-off

  Requires disciplined seeding and migration hygiene on every release.

• Challenge

  A demo environment with real-looking accounts is a production security risk waiting to happen.

  Decision

  Development seed accounts are gated so they can never be created in a production environment.

  Trade-off

  Slightly more configuration per environment, and no chance of a well-known password reaching production.

• Status

  Delivered · Private platform

• Clients

  Flutter student app + web dashboard

• My role

  Product planning and full-stack delivery

• Languages

  Arabic and English, full parity

IMMAR is the project that convinced me most of my job is drawing boundaries. The hard parts were not the modules — courses, quizzes, attendance, finance are all solvable. The hard part was deciding what each role is allowed to see and holding that line while the feature list grew.