Khatma for Recovery — Completion Tracking on a Shared Reading
The same idea, dedicated to someone still here — and this time it knows what has actually been read.
Built by us, for us — there is no client on this one
Overview
A second khatma application, dedicated to someone’s recovery rather than their memory. It adds the piece the first one was missing: a portion can be claimed and then separately marked finished, so the board distinguishes what is spoken for from what is done.
What this proves
Iteration on a shipped idea. The second build exists because using the first one revealed the gap.
Key features
Claimed and completed are two states
Taking a portion and finishing it are separate actions writing to separate fields. The board can therefore answer the question that actually matters — how much has been read — instead of only how much has been promised.
Its own table, not a shared one
The recovery khatma writes to its own assignments table rather than reusing the memorial one. Two dedications with different meanings should not share a namespace, and separating them keeps either from ever appearing in the other.
A tone shift, not just a colour change
The copy throughout is rewritten for a living person — an invitation to recovery rather than a dedication to a memory. The two applications share a structure and share almost no words.
Why a second one
The first khatma tracked claims. In use, the group kept asking a question it could not answer: has this actually been read yet? A claim is an intention, and intentions do not complete a reading. So the second build separates the two, and the progress figure on the board means something as a result.
It is a small change and a real one, and it is the reason both are listed here rather than one.
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
- Shares the first build’s limits: no authentication, and claims can be impersonated
- Completion is self-reported and unverifiable by design
- Uniqueness is enforced in the client rather than by a database constraint
- Arabic only, no automated tests, no admin tooling
Portfolio assessment
- Visual design
- 6.0 / 10
- Technical complexity
- 4.0 / 10
- Interactivity
- 5.0 / 10
- Business value
- 4.0 / 10
- Portfolio appeal
- 5.0 / 10