Building a Quran Learning Mobile App: What 100K+ Installs Taught Me

The numbers behind this article

The AzanGuru iOS app currently holds a 4.6★ rating across 16 reviews on the App Store. The Android app has crossed 100,000+ installs on Google Play. The audience is global, primarily English-speaking learners and parents of young learners. I built both apps end-to-end as sole developer, on a stack of WordPress + WPGraphQL + Next.js + React Native.

This article is what I learned shipping the product to that audience. The technical architecture is covered in my WordPress + GraphQL article. This article is about the product lessons.

Lesson 1 — Quiet, calm UI is non-negotiable for learning apps

The first design draft for AzanGuru was modern, colourful, and tightly packed with progress information. The reaction from early users was uniform: too busy. The audience is focused on a sacred subject. They want the app to feel respectful and unhurried.

We rebuilt the entire visual language around calm: more whitespace, a softer colour palette, fewer surface decorations, and a deliberate slowness in animations. Retention measurably improved. The lesson generalises: if your audience comes to your app for focus, the UI must reward focus.

Lesson 2 — Live classes via Google Meet beat a custom video stack

The original plan was a custom video classroom built on WebRTC. We prototyped it. Then we measured how much time engineering would spend maintaining a video stack that handled corner cases (poor networks, dropped reconnects, mobile-data fallbacks) and concluded the engineering cost was not justified.

We integrated Google Meet for live classes instead. Teachers post a Meet link inside the lesson; students join. The user experience is good, the engineering load is zero, and the time saved went into the assessment system that students actually use more often.

The lesson: do not build infrastructure that a giant company will give you for free or near-free. Build the parts that are unique to your product.

Lesson 3 — Multi-audience UX is harder than multi-device UX

AzanGuru serves three audiences: children, adult learners, and teachers. Each needs a different mental model.

• Children need engagement loops and gentle progress indicators. They will not read large blocks of text.
• Adult learners want detailed progress, structured curriculum, and the option to dig into theory.
• Teachers need scheduling, student management, and class notes.

The first version used a single navigation model with role-based filtering. Each role saw a subset of the same screens. It did not work. Children were confused by labels designed for adults; teachers were frustrated by the lack of an admin-style overview.

The rebuild used role-based home screens: same backend, same data, but distinct navigation per role. Each user lands on a home screen designed for their workflow. Cross-role data is exposed through deep links rather than shared navigation. Conversion to active user improved on every role.

Lesson 4 — In-app purchase is its own product

I underestimated the complexity of in-app purchase. The mechanics — calling StoreKit or Google Play Billing — are fine. The product work around it is hard:

• Receipt verification must run server-side. Trusting the client is how piracy happens.
• Refund and restoration flows must work cleanly. Users do refund.
• Subscription state must reconcile between the store and your backend on every app launch.
• Different countries have different price points and currencies. App Store Connect supports configurable per-country pricing, and using it well lifts conversion.

If your app has paid plans, allocate at least three weeks of focused work to in-app purchase. Plan it as a sub-project.

Lesson 5 — The first crash is always the platform-specific one

Cross-platform code that works on iOS often crashes on Android, and vice versa. The culprits in the first few weeks of AzanGuru's life:

• Audio playback timing assumptions that worked on iOS and silently failed on Android.
• A keyboard layout assumption (iOS's "Done" key vs Android's "Next") that broke a form flow.
• A back-button gesture that conflicted with a Android system gesture but had no equivalent on iOS.

Sentry crash reports caught all of these within the first 72 hours after launch. The lesson: test on real devices of both platforms before launching, then watch crash reports compulsively for the first month.

Lesson 6 — Ratings come from prompts, not goodwill alone

Without explicit prompts, even satisfied users do not leave reviews. AzanGuru shows a "rate the app" prompt to users who have completed three lessons and have been using the app for at least a week. The prompt uses the native Apple SKStoreReviewController and the Google In-App Review API, so it does not interrupt the user — it just surfaces the rating UI inline.

The 4.6★ rating with 16 reviews on iOS reflects this discipline. Without it the count would be much lower.

Lesson 7 — Notifications can save retention or destroy it

Push notifications are powerful and easy to abuse. Two principles I follow:

• Earn the permission. Do not ask for notification permission on first launch. Ask after the user has completed their first lesson and would naturally want reminders.
• Send fewer. One scheduled reminder per day at the time the user usually engages, plus important transactional messages, is the right cadence. Beyond that, opt-outs spike.

Topic management matters too. Use topic-based subscription so users can mute the categories they do not want without disabling notifications entirely.

Lesson 8 — Internationalisation pays back

AzanGuru launched in English only. As the audience grew, the team began localising the interface into other languages. Each new language unlocked meaningful new install volumes on the relevant markets. Right-to-left support — important for Arabic — was the most invasive change but absolutely worth it.

The lesson generalises: every global product should plan for localisation from the schema up. Strings should never be hardcoded.

Lesson 9 — Sole-developer apps can scale further than you think

AzanGuru's backend, mobile app, and website have all been built and maintained by me. The 100K+ Android installs and the 4.6★ iOS rating exist on an architecture deliberately chosen to be operable by one person: WordPress for content, GraphQL for the API, Expo for the mobile builds, Vercel for the website, and a single tuned VPS for hosting.

The advice for solo founders: pick technologies that have great managed-service options. Expo for builds. Vercel for the web. Cloudflare for the CDN. The hours you save on infrastructure go into product.

Frequently asked questions

How much did the first version cost to build?

Sole developer, full-time, roughly four months end-to-end for v1 across backend, web, and mobile. Calendar time longer because of test cycles, store reviews, and content production.

What is the most important metric to watch?

Lesson completion rate. Active users start lessons; engaged users complete them. Optimising for completion ripples through retention, ratings, and revenue.

Is React Native really enough for a media-heavy learning app?

Yes, with one caveat: video and audio modules need careful selection and a small amount of native bridging. Once those are right, the rest of the app sits comfortably in JavaScript.

Also read

• Case study: AzanGuru
• WordPress + GraphQL: Mobile App Backend in Two Weeks
• Shipping a React Native App to Both Stores

Working on a mobile learning product?

If you are building an education or learning app and want a second pair of eyes on the architecture, get in touch. I have shipped one to scale and would happily share more.