Case study · Halaali · Updated
Shipping an AI-enabled mobile product end to end
I’m Abdul Moiz Shahzad, co-founder and CTO of Halaali, a Muslim super app on iOS and Android that I co-founded in December 2024 and engineered alone. This page explains what the product does, what I built, where the in-app agent fits the backend, how a one-engineer team releases and operates it, and which numbers I will and will not print.
What Halaali does
Halaali helps Muslims find and use the halal parts of a city: restaurants, grocers, butchers, and masjids with prayer times, a qiblah compass, a lifestyle feed, and services such as charity, nikah, and legal help. The product site lists more categories as coming soon, and I am leaving those off this page until they ship. The apps are live on the App Store and Google Play, and the platform runs in more than one country, with Canada and Mauritius as the two markets the admin tooling was built around.
What I built and own
The apps are React Native with Expo, one codebase for both stores. The backend is Supabase on PostgreSQL with PostGIS, which is where the geospatial search lives: a query for halal food near you is a spatial query against indexed places. Payments run on Stripe and are live. Around the consumer app sit an admin portal and a partner portal, and the admin is country-scoped: queues, media, audit, and restore are separated per market, with a dashboard per country. The native surface goes beyond the app itself, with an iOS prayer widget and an Android masjid widget that share the app’s data modules.
Co-founded means partners exist and the company is not mine alone. Engineered alone means every one of those pieces was designed and written by me, and I still maintain them.
Where the agent fits
Habibi AI is the in-app agent, and it is in production. It is a tool-calling agent built on the Vercel AI SDK, with retrieval over pgvector and a context that knows where the user is. Its work is halal-business discovery, deals, and parsing promotional flyers into structured data. The model chooses a tool and its arguments; the tool is a function the app already had, and the code runs it and returns the result. The agent never reaches the database with anything other than the tools it was given, which is the line I would draw in any product where a model sits next to real data.
The examples I would use to show this are synthetic. No user transcript, name, location history, or payment detail appears on this page or will, because building the application does not make its users’ data mine to publish.
Operating it alone
Releases go out through Expo’s EAS builds in stages, so a build reaches testers before it reaches a store listing. Push notifications are the part that taught me the most. New posts publish to a feed and fan out as notifications, and a broadcast that runs in chunks has to account for every chunk: in mid-2026 I hardened that accounting and added skip and failure logging, after finding that a silent partial send is indistinguishable from a successful one until someone complains. Multi-country support was the other large piece of 2026: a second market meant per-country queues, media, audit trails, and a second yearly reporting lane.
The numbers, and the ones I will not print
The database held 1,300+ indexed locations when I last verified the count in 2026-08; an indexed location is a place record in the product database. The product’s own site advertises a larger figure counted differently, and I have not reconciled the two definitions on this page, so the verified one stands. The user count stays off this page until I publish what it counts and over what period. Revenue is not disclosed.