The running stack
- Mobile: Flutter on Android and iOS, with seven languages (en, ar, ur, kn, te, ta, ml).
- API: Node.js on an always-on cloud VM so Maghrib is not a cold start.
- Auth & push: Signed-in accounts and push notifications. Prayer reminders also use local timezone-aware scheduling so Iqama alerts are not an hour off.
- Data: A hosted database for masjids, members, announcements, Azan sessions, Ask Imam threads, finance rows.
- Live audio: a self-hosted media server (see the VoIP article).
- Payments: licensed processor for marketplace checkout — card numbers stay with the processor.
Cross-platform clients
One codebase ships Google Play (com.myalmasjid) and the App Store. iOS-only surfaces — Live Activities / Dynamic Island — are feature-detected, not stubbed with a fake Android widget. Ads are role-gated: Imam and Muezzin screens stay clean while they are on duty.
- Shared domain models (masjid, session, role) live in the app and are mirrored on the API — we do not let the two drift silently.
- The API is the permission source. The UI hides buttons, but a forged HTTP call still 403s.
- Qibla and Tasbih work offline. Prayer times and live features require the network, which we state in FAQ copy so AI snippets stay accurate.
Why five roles, not one “admin” flag
Masjid politics is not a SaaS “owner vs user” checkbox. A Muezzin must start Azan without seeing donation ledgers. An Imam must answer Ask Imam without being the only person who can approve members.
| Role | Typical person | Must have | Must not have |
|---|---|---|---|
| Member | Worshipper | Listen, Ask Imam, Sadaqah | Live publish, finance write |
| Muezzin | Caller of Azan | Publisher token for Azan | Full ledger |
| Imam | Religious lead | Azan + Khutbah, answers | Silent role changes for the whole committee |
| Mutawalli | Trustee | Members, announcements, KYC | Need to be the microphone every Salah |
| Admin | Committee operator | Settings, staff snapshot restore | Bypass KYC for Sadaqah |
When a masjid is deactivated we snapshot the staff roster so reactivation does not force every Imam to re-onboard from zero. That is a community-ops detail you will not find on a generic “mosque app” landing page.
What lives on the server vs on-device
- On device: Qibla math, Tasbih counts, locale, notification permission, cached prayer times.
- On server: canonical iqama, announcements, Ask Imam threads, live-session records, KYC flags, finance entries.
- Never on server: Qibla GPS trails (compass is local), payment card numbers, media-server API secrets.
How we ship without a 20-person DevOps team
- The API and the live-audio server run as two separate services. Hostnames stay stable if the region changes.
- The API stays warm. Maghrib is not a cold start.
- Secrets are injected at runtime — media credentials never sit in the app or in Git.
- Website on Cloudflare Pages: static HTML, one CSS file, SVG diagrams. That is the Core Web Vitals strategy — less JavaScript, not more.
Related: Live Azan VoIP · Ask Imam · About.