Skip to content
AMTEXConsulting

Case study · Technology

Kareeb: a community app built on open map data and a realtime backend

A mobile and web app that helps people find nearby mosques and community businesses, see accurate prayer times and keep a personal practice journal, with the directory kept fresh from OpenStreetMap by a scheduled sync.

Client
Kareeb
Industry
Technology
Solutions
Application DevelopmentMobile Development
Technology
React NativeExpoNext.jsSupabasePostgreSQLTypeScript

Challenge

Directory apps rot. Listings are entered by hand, nobody maintains them, and the single most important piece of information for a mosque, the time the congregation actually prays, is different from the calculated prayer time and changes through the year. Kareeb needed a directory that maintains itself and a data model that keeps those two kinds of time apart.

Context

AMTEX is building Kareeb as a product: the Expo mobile app, the Next.js web app, the Postgres schema, the synchronisation functions and the release pipelines. It is in active development, with public release to follow.

Solution

An Edge Function syncs mosque data from OpenStreetMap into Postgres on a schedule, so the base directory is maintained by the largest open mapping community rather than by the app. Congregation times are a separate, community-maintained layer on top of each mosque, distinct from calculated times, and changes stream to open apps over Realtime. A nearby directory of halal businesses and community services adds listing verification and offers, so a business cannot appear verified or promote an offer without a check.

  • Personal practice features: salah recording with a considered flow for missed prayers, Quran reading journeys and a tasbeeh counter that persists across sessions.
  • Row-level security so personal records are readable only by their owner.
  • Android adaptive icons, iOS build pipelines and over-the-air updates from day one.

Business impact

Kareeb's directory does not depend on anyone keeping it up to date by hand, and its most sensitive data, a person's own religious practice, is protected at the database layer. Figures will follow the public release.

Key takeaways

  1. 01Source reference data from a maintained open dataset and layer community corrections on top.
  2. 02Model the distinction users care about (calculated time versus congregation time) explicitly.
  3. 03Protect personal records with database policies, not application code.

Facing something similar?

We will walk you through how we approached this one and what would be different for you.