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: a public prayer display, the mosque administrator dashboard, and mobile mosque discovery.
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 complete product system—not a collection of screens.
The live platform covers the shared foundation, admin experience, public display experience, and customer discovery. Daily-use enhancements continue to ship; widgets and other advanced capabilities remain roadmap work.