SafSaf

The problem

Religious communities run on software that does not exist for them. A masjid with a Hifdh program tracks memorisation progress in spreadsheets, takes admissions on paper, announces prayer times on a whiteboard, and manages Hajj packages over WhatsApp. Each of those is a real product, and none of them are worth building alone for one community.

Saf grew out of the grading app I built for Darul Uloom Michigan. Once one community had working school management, the next question was immediate: what about admissions, what about prayer times, what about the pilgrimage packages.

Approach

Five products, one platform, per-community portals. Arshad handles school management. Tajul Haramain handles pilgrimage packages. Then admissions, prayer times, and staff time clock. Each participating community gets its own portal, but they share infrastructure — otherwise every new community means a new deployment to maintain.

Authorisation server-side, without exception. The most consequential thing I changed was moving password and role verification out of the client and into a Supabase edge function, with Postgres row-level security enforced across all four portals. Multi-tenant systems where clients assert their own role are one mistake away from a community's student records being readable by another community.

Migrations forward-only, CI typed. 300+ PRs and 43 deploys across a live system used by 30+ educators and admins. Forward-only SQL migrations mean no deploy can silently roll a schema backwards under live data, and typed CI catches the class of error that only shows up when a real admin clicks the thing at 9pm.

Where it stands

Live with 200+ users. Currently integrating AI features and an investor demo hub ahead of a venture raise and a scholar-backed public launch.

The codebase is private. If you want a walkthrough, send me a message.