Masajidna
Designing one coherent mosque platform across three Flutter applications—without losing reliability, affordability, or ease of use.
Live experiences for mosques and their communities.
These are real screens from the working platform, which I independently built, own, maintain, and update. It is published under Muhkam Limited.
One community. Three very different interfaces.
Mosque administrators needed a practical way to manage information. Community members needed trustworthy prayer times and discovery. Public display screens needed a clear, glanceable presentation that stayed useful when connectivity became unreliable.
The engineering challenge was to create three focused experiences backed by one consistent data model—while keeping database reads, operational cost, and maintenance complexity under control.
A shared source of truth.
Model the data around real usage—not theoretical purity.
Prayer times were embedded within mosque documents so common screens could load the information they needed without triggering a chain of extra reads. Firestore persistence supported an offline-first experience and reduced repeated network activity for returning users.
Concrete system rules.
Numbers drawn directly from the product and implementation specifications.
Shared domain core, admin app, customer app, and display web app.
Super admin, applicant, admin, manager, viewer, and customer/guest.
Manual entry, automatic calculation, and validated CSV import.
Random six-digit display codes rotate and expire automatically.
Simultaneously active display announcements rotate on a fixed cadence.
Photon search begins after three characters and returns up to five results.
Can I reach a mosque before prayer starts?
The “Catch Prayer” experience combines the user's location, upcoming prayer times, and the Google Distance Matrix API. It filters options by realistic travel time instead of showing the nearest mosque in a straight line.
- Location-aware mosque candidates
- Travel-time calculation through Google APIs
- Prayer-window comparison
- Useful fallback and error states
Security and resilience were product features.
Firebase App Check, query-size restrictions, and rate limiting helped protect backend resources. Offline persistence made the applications useful through intermittent connectivity. Each safeguard was designed around the way the platform would actually be used.
A working product system—not a collection of screens.
All capabilities described in this case study are implemented and working. I continue to maintain and update the product. Usage and performance metrics are omitted unless they can be supported by analytics or another verifiable source.