Key Outcomes
3 stakeholders
admin, instructor, and student, each with a dedicated, fully scoped experience
Launched
in 2 weeks, from first build to a live, working platform
3 cohorts
live and running, with paying students by the third week
3 languages
English, Arabic, and Urdu, logical CSS properties only, never hardcoded left/right
Overview
- •
Industry: EdTech / Islamic Education / Non-profit
- •
Platform: Web-based LMS (three-role cohort platform)
- •
Users: Students, instructors, and program admins
- •
Stack: Next.js 16 (App Router) + React 19 + TypeScript strict · Supabase (Postgres, Auth, Storage, RLS) · Drizzle ORM · next-intl · Resend
Background
Quranification runs small, live cohorts where students learn the Qur'an and Islamic knowledge directly from real teachers, high-touch, mentorship-style education, not a self-paced course catalog. The founder's own framing sets the bar: "we are not in the business of selling courses, we are in the business of cultivating lifelong students of the Qur'an and Islam," which means the platform's job is to model people, not transactions, a student is someone with a long relationship to the institution, not a row attached to a purchase.
Before the platform, running a cohort meant holding applications, Zoom links, assignments, and feedback together across spreadsheets and DMs, workable for one small group, not for parallel cohorts with multiple instructors who each need to see only their own students.
Ownex Labs built the software layer to remove that operational friction: a stranger can discover a course, apply, get accepted, log in, see every session with its join link, submit assignments, and get feedback, with zero manual work from staff beyond the accept/reject call. An instructor runs their own cohort end to end, sessions, assignments, grading, attendance, announcements, without needing staff to do any of it for them, and without being able to see another instructor's cohort at all.
- •Replace spreadsheets and DMs with one platform for the full cohort lifecycle
- •Give each instructor a fully self-serve, cohort-scoped dashboard
- •Guarantee student and instructor data privacy with Row Level Security on every table, not app-layer checks alone
- •Support Arabic and Urdu (RTL) as a day-one requirement, using logical CSS properties everywhere
- •Keep every piece of Qur'anic text, translation, and tafsir sourced, human-reviewed, and never model-generated
The differentiator is the teacher, not the platform, so the engineering rule that follows is: don't over-build automation that removes the human from the loop, and don't assume this needs to scale like a SaaS product.
The Challenge
Business Challenges
- Applications and acceptances tracked manually across spreadsheets and DMs, no single source of truth for who is enrolled or who is teaching whom
- Instructors needed to run sessions, assignments, and feedback without depending on staff for every step, while never seeing another instructor's cohort or students
- Religious content, Qur'anic text, translations, tafsir, needed strict sourcing and a human-review gate, never model-generated or paraphrased, with unreviewed content blocked from publishing
- A student record has to survive courses, cohorts, and platform changes, so identity had to be modeled as a durable person, not a purchase row
Operational Pain Points
- Session join links, recordings, and reminders sent by hand, easy to miss or send late
- Assignment submissions and feedback scattered across email threads with no shared record
- No timezone-aware session view, every instant needed to be stored in UTC and rendered in each student's own timezone
- Deciding when a course or cohort record could be safely deleted versus needed to be archived, since a batch with even one enrolment is part of somebody's record, not a mistake to undo
Technical Challenges
- Enforcing that a student can never read another student's submission at the database layer, not just the UI, and that an instructor's visibility is scoped per cohort via a many-to-many join, not a blanket role flag
- Building genuine three-role access entirely through Postgres RLS, staff via row existence in a `staff` table, never a hardcoded email list; instructor via `cohort_instructors`, never automatically staff
- Cross-profile name resolution, forums, DMs, and the alumni directory all need one user to see another's name safely, which the base `profiles` RLS (strictly own-row-or-staff) does not allow, so dedicated SECURITY DEFINER "safe views" re-implement the real access check per feature
- Supporting Arabic and Urdu RTL layouts without ever using hardcoded left/right, using logical CSS properties throughout
- Choosing and later reversing a payment gateway: Stripe does not support Pakistan as a merchant/payout country at all, caught before building the wrong integration, and replaced with Safepay, a State Bank of Pakistan–regulated processor, with the idempotency ledger (`webhook_events`, unique per external event id) already in the schema ahead of that build
The Solution
Ownex Labs built Quranification as a three-role Next.js platform on Supabase, with Row Level Security written into the same migration that creates each table, so access control lives in the database, never only in app code. The public side covers discovery, applications (student and teacher, with intro-video upload for teacher applicants), and course pages; the admin side handles application review, cohort and instructor assignment, cross-cohort oversight, announcements, and audit logging; the instructor side is a scoped dashboard for sessions, assignments, grading, attendance, and announcements on their own cohort only; the student side covers magic-link sign-in, a timezone-aware session list and unified calendar, assignment submission, quizzes, and progress tracking. A community layer, forums, DMs, office hours, group formation, an alumni directory, and a leaderboard, sits on top so relationships outlast any single cohort. Every layout is built with RTL and Arabic/Urdu support from the first component, and the full RLS policy set is exercised by an actual Vitest suite running against an in-memory Postgres (PGlite) that replays the real migrations, not mocks, so a broken access rule fails a test before it reaches production.
Core Architecture
Implementation Process
Data model & access control first
Modeled people before transactions (stable profile UUIDs that outlive any single cohort), then wrote RLS for staff, cohort-scoped instructors, and self-scoped students into the same migration that created each table, and set up the Vitest + PGlite suite so every future policy change gets a real isolation test.
Core cohort platform
Built the public course/application flow (student and teacher applications, intro-video upload), admin application review (accept/waitlist/decline), and cohort + instructor assignment, including the many-to-many `cohort_instructors` join for co-teaching and multi-cohort instructors.
Instructor & student dashboards
Shipped the scoped instructor dashboard (sessions, assignments, rubrics, weighted gradebook, attendance, announcements) and the student dashboard (timezone-aware session list, unified calendar, submissions, quizzes, feedback, progress tracking).
Community & content integrity
Built forums, DMs, office hours, group formation, an alumni directory, and a leaderboard on dedicated safe views, alongside a content model where Qur'anic text is imported once from a single citable dataset and stored verbatim, and every translation/tafsir record carries a source and a human reviewer before it can publish.
Results & Impact
(Platform status)Access Control
- RLS-only access control, enforced at the database layer on every table, never app code alone
- 21 files of Vitest RLS-isolation tests against real migrations, not mocks
Student & Instructor Experience
- Self-serve instructors run sessions, grading, attendance, and announcements without staff
- Timezone-aware session list and unified calendar, every instant stored in UTC
Localization & Content
- RTL-first Arabic and Urdu supported from the first component, logical CSS properties only
- Sourced every religious content record carries a source and a human reviewer before publishing
