Skip to content
Client product

Al-Tafawuq School System

One school, four repositories, and a parent who only ever sees a WhatsApp link.

The Al-Tafawuq administrator dashboard: attendance over thirty days, tuition totals, pending tasks and the latest payments.

The interface above is a presentation mockup of the product, not a screenshot captured from a running system. The interface compositions further down this page are built from the platform’s real module structure — these are private client and commercial platforms.

Role
Full-stack engineer
Year
2025
Status
Delivered · Deployed
Category
Dashboard

A centralised, Arabic-first school management platform covering students, classes, attendance, academic records, reports and notifications, built for administrators, teachers and authorised staff across a .NET backend, a Next.js dashboard and a static bilingual landing site.

The problem

School operations run on paper registers, personal phones and memory. The information a parent wants — attendance, marks, fees — exists, but it is scattered across staff who each hold one piece of it.

The outcome

A deployed platform where all business rules live in one API, verified end to end with seed data and prepared sample accounts before handover.

Stack

  • .NET 8
  • ASP.NET Core
  • EF Core
  • PostgreSQL 16
  • Redis
  • Next.js 15
  • TypeScript
  • Tailwind CSS
  • Railway

Services

Back to all work

One product, four repositories

The platform is split into four independent repositories that behave as one product — and the split only works because of a single rule about where business logic is allowed to live.

  • Landing

    Public, static, bilingual

    • Next.js static export

  • Dashboard

    Admin, teacher, accountant, parent, student views

    • Next.js 15
    • TypeScript
    • Tailwind CSS

  • Backend

    All business rules live here

    • .NET 8
    • EF Core
    • PostgreSQL 16
    • Redis

  • Docs

    Traceability, RBAC matrix, run and release guides

    • Specs
    • QA reports
    • Deployment guides
Four repositories, one contract between them.

Roles and daily operations

A school is a permission problem wearing a timetable. A teacher records attendance for their own classes; an accountant sees fees but not academic records; an administrator sees everything; a parent sees exactly one child. The modules are ordinary — the access model is where the work is.

  • Students, classes, attendance and academic records form the operational core.
  • Reports and notifications read from that core rather than maintaining their own copies.
  • An RBAC permission matrix is maintained as documentation, so access can be reviewed without reading source code.

Delivery and verification

Handover is where school software usually fails: it works on the developer’s machine and nowhere else. The platform ships with a single run script, seed data, prepared sample accounts, an environment-variable matrix and a QA report, so someone who has never seen the project can bring it up and sign in.

  • Deployment

    Railway, configured environments

  • Verification

    Auth, permissions and major workflows with seed data

  • Default language

    Arabic

Next case study

Building something in this space?

I am available for a limited number of projects. Tell me what you are working on.

Start a project