MentorTracker

I mentor a weekly cohort of students, and the honest version of that job involves a lot of asking people how their week went and getting a shrug. A worship habit is private and daily, and the useful thing for a mentor to see is a trend, not a confession.

The first version of MentorTracker solved the tracking half and left the mentoring half thin: one database, no real notion of an organization, and a mentor view that was mostly a list. It worked, and hundreds of students used it, which is exactly when a weak data model starts to hurt.

Real users were already on the old app, so whatever we built had to end in a migration, not a relaunch. The data is sensitive in a way that is easy to underrate: a mentee's log belongs to the mentee, a mentor sees an aggregate, and a coordinator sees less again. That has to be enforced by the database, not by whichever screen we happen to render.

Apple added its own rule: an app offering third-party sign-in needs Sign in with Apple. And this is a side project for two people, so anything we could not test automatically would not stay correct.

A ground-up Expo and React Native rewrite in a fresh tree, with the old app kept as read-only reference. Firestore rules are deny-by-default, and every relationship document is written only by a Cloud Function, with deterministic document IDs so an invite cannot be forged by guessing.

Mentors get a roster, per-student goals, attendance programs that generate their own sessions, and a history view spanning 8 to 12 weeks. Students get streaks, custom goals, a Quran bookshelf, and iOS home-screen widgets. Every phase had to pass a gate of typecheck, lint, tests, web export, and rules tests, plus an adversarial review, before we called it done.

I own the product: the roadmap, the data model, the security rules, the mentor-facing features, and the release decisions. I also wrote the UX round that followed v2.0, which added goal editing, a rebuilt mentor goal sheet, attendance programs, excused days, and the reports history.

Tarik Metin co-developed the app with me and ships the App Store releases, including v2.0 with Sign in with Apple, the rewards engine, and the Quran reader work. The adversarial reviews caught real bugs of mine, including a streak that could break at midnight on a day marked excused.

Version 2.0 has been on the App Store since August 2026, and the app is used by hundreds of students. The suite that gates a release is 2,626 Jest tests, 129 security-rules tests, and 288 Cloud Functions tests.

That gate, and the reviews that run beside it, caught real bugs in my own data model before they shipped. I run usability rounds with the students who use the app and build what comes back. I am not quoting a monthly-active number, because I have not pulled one I would defend.

Two things. The app ships under my collaborator's Apple Developer team, so I cannot cut a release build myself. I would set up a shared team on day one instead of discovering the gap under a deadline.

Second, I would design the data model around organizations from the start. Version 1 had no real notion of one, and most of the v2 migration work was retrofitting that structure under data real students were already using.