Khatma — Shared Quran Reading, Coordinated in Real Time
Thirty portions, one family group, and nobody reading the same one twice.
Built by us, for us — there is no client on this one
Overview
An Arabic, right-to-left web application for organising a khatma — a complete reading of the Quran divided among a group in memory of someone who has died. Readers claim one of the thirty portions, the claim is held centrally so two people cannot take the same one, and the group watches the reading complete.
What this proves
That we build for our own community, in Arabic first. This is RTL as the native direction, not a translation layer — and a genuine shared-state coordination problem underneath.
Key features
Claiming a portion, exactly once
A reader picks a juz and puts their name on it. The claim is checked against the store before it is written, and an attempt on an already-taken portion is refused with a message telling the reader to choose another — the one piece of correctness the whole application rests on.
A live board of thirty
All thirty portions render as a board showing which are claimed, by whom, and how many remain — so the group can see the reading fill in rather than asking each other.
A tasbih counter that survives a reload
Counts are kept in local storage on the reader’s own device — deliberately not on the server, because a personal count is nobody else’s business and needs no account to work.
No account required
A reader types a name and takes a portion. Requiring a sign-up would have halved participation among exactly the family members this is for, so identity is a name on a claim and nothing more.
Arabic typography, chosen not defaulted
Set in Amiri and Noto Naskh Arabic rather than a system stack, with the document direction right-to-left from the root element — the layout is native, not mirrored.
The problem it solves
A khatma for someone who has died is normally organised in a group chat: someone posts the list of thirty portions, people reply claiming numbers, and within an hour the thread is unreadable, two people have taken juz 12, and nobody is sure whether the reading was finished. It is a coordination problem being solved with a medium that cannot hold state.
This puts the state somewhere it belongs. The list is authoritative, a claim is atomic, and the remaining count is a fact rather than a scroll-back exercise.
Engineering
Supabase’s PostgreSQL REST interface is called directly with `fetch` — no client library, no bundler, no build step. The application is one HTML file containing its own styles and behaviour, which means it can be put online in minutes and shared as a link in the same chat it replaces.
Two tables carry it: the khatma itself, and the portion assignments keyed to it. A claim is a conditional insert; the board is one ordered select.
Not demonstrated by this project
Stated plainly, because a portfolio is more useful when it is precise about its limits.
- Self-initiated, not a commissioned client engagement
- No authentication — a claim is a typed name, and it can be impersonated
- Uniqueness is enforced by a check-then-insert in the client, not a database constraint
- No live push — the board refreshes on load and on action, it does not stream
- Arabic only — there is no English interface
- No automated tests, and no moderation or admin tooling
Portfolio assessment
- Visual design
- 6.0 / 10
- Technical complexity
- 5.0 / 10
- Interactivity
- 6.0 / 10
- Business value
- 5.0 / 10
- Portfolio appeal
- 7.0 / 10