Independent product November 2025 to present
Masajidna
One set of information. Three different places to use it.
I independently designed and built Masajidna. I own the product and continue to maintain it; it is published under Muhkam Limited.
- My role
- Owner and sole developer
- Tools
- Flutter, Firebase, Riverpod
- Applications
- Administrator, community and public display
- Today
- Live and actively maintained
Ownership and brief
Useful at a desk, in a pocket and across a room.
Mosque teams need to manage prayer times and announcements. Community members need to find that information. Public displays need to communicate it at a glance.
My responsibility covers product design, application development, shared architecture, Firebase integration, release and ongoing maintenance across all three experiences.
The constraints
Different permission levels, intermittent connectivity, English and Arabic layouts, and a data model that stays practical to read and maintain.
The applications
Different interfaces, with a shared foundation.
Shared domain core
Common models and logic connect the focused applications. Firebase provides authentication, Firestore data and server-side functions.
- AdministratorManage
- CommunityDiscover
- Public displayInform
Data decision
Design the read path around the screen.
Prayer times are embedded in mosque documents, keeping information common screens need together. Firestore persistence supports access to previously loaded information when connectivity is interrupted.
Keep common reads together
Load mosque information and its prayer schedule without assembling every screen from a chain of separate document reads.
Keep updates consistent
Embedding data simplifies reads but makes document structure and updates important. Cached information can be older than the server's current state.
Catch Prayer
Nearest is not always reachable.
Catch Prayer combines the user's location, upcoming prayer times and Google travel-time data. It asks whether the user can reach a mosque before prayer starts, rather than showing distance alone.
- Find candidate mosques around the user.
- Estimate travel time through Google APIs.
- Compare arrival time with the prayer window.
- Handle unavailable location or travel-time data.
Travel estimates depend on an external service and changing conditions. An estimate is not an arrival guarantee.
Access and resilience
Different permissions. Shared responsibility.
Six roles separate super administrators, applicants, administrators, managers, viewers, and customers or guests. Firebase App Check, query restrictions and rate limiting help protect backend resources.
Manual entry, automatic calculation and validated CSV import support different ways mosque teams maintain prayer times. English and Arabic interfaces include right-to-left layouts.
Short-lived display pairing
Six-digit pairing codes expire after five minutes, limiting how long an unused code remains valid.
Useful during an interruption
Local persistence keeps previously loaded information available. Stored information still needs to be distinguished from a fresh result.
Testing
Test the rules, then the boundaries.
The test strategy covers time calculations, connection states, permissions and workflows between applications.
Domain and interface coverage
Unit tests cover schedule calculation, next-prayer selection, reachability, parsing, validation and timezone boundaries. Widget tests exercise loading, permission, empty, stale, offline, success and error states.
Integration and backend coverage
Integration tests cover authentication, administrator ownership, display pairing and imports. Firebase Emulator Suite tests exercise Firestore rules, Storage rules and Cloud Functions.
Ongoing ownership
Released, working and still maintained.
Three connected applications. Six permission roles. Two languages, including Arabic with right-to-left layouts.
My responsibility continues beyond the first release: keeping the applications, shared logic and integrations working together.