MuslimWise
·PRODUCT MANAGER+PRODUCT DESIGNER+SOFTWARE ENGINEER·IOS/MOBILE/AI-ASSISTED/SOLO-PROJECT/SWIFTUI
A prayer habit app that never punishes you for missing a prayer — designed, built, and shipped solo, AI-leveraged.
A prayer habit app that never punishes you for missing a prayer — designed, built, and shipped solo, AI-leveraged.
The flower garden — one bloom per completed prayer, never decays
I designed the product, designed every screen, and wrote the code for MuslimWise — alone, part-time, around a full-time role in the CEO Office at Brick, an open-finance fintech. I used AI as execution leverage throughout, but the product decisions, the interaction design, and the judgment calls on what to build — and what to cut — were mine.
I grew up with an accountability guardian I didn't choose: my parents checked whether I'd prayed. It felt like an obligation. Later I understood what a quality prayer actually does — it's a recharge, a forced pause out of the hustle of the day that leaves you calm and assured, not just a box to check.
Then I left home, and the guardian disappeared. What followed was a loop that got worse over time: I prayed less often, and when I did pray, I was rushed and not intentional about it. Because I didn't treat it as rest, the quality of the prayer dropped — it started to feel like a chore that drained energy instead of one that recharged it. A bad experience made me pray even less often. A second loop fed the first: I'd lose track of time, get absorbed in work or doomscrolling, and end up praying in the last few minutes of a window, rushed. Eventually I became reliant on external triggers — praying mainly when a life event pushed me to ask God for help. That's a bad place to be, because every trigger is external and none of it is habit.
The problem was never just "remind people to pray." It was quality prayer that recharges you — and a way to get back to it without an external accountability structure, and without the process itself feeling like a punishment.
Most prayer-tracking apps default to streak mechanics — daily fire icons that grow the longer you keep an unbroken chain. The failure mode is obvious once you name it: the moment your streak breaks, the fire goes out, and everything you built up feels erased in one bad day. That's the wrong model for something you're supposed to do five times a day, every day, for life. Life is hard, and prayer shouldn't be treated like a punishment for the days it doesn't go perfectly.
Islam already has an answer for this: Qada. If you miss a prayer, you can repay it later — the religion itself is built to be forgiving of lapses, not punitive. I ported that directly into the product: regardless of when you last prayed, every prayer you did complete still counts. It's still your flower, carried forward permanently. Never-decay isn't an absence of a game mechanic — it's a deliberate translation of an existing theological concept into interaction design.
The garden metaphor followed from the same place. Heaven, in Islamic tradition, is often described through flowers, trees, and flowing water. Growing a garden of flowers, one per completed prayer, became a literal way to visualize building your own place of serenity — not a generic points system bolted onto a to-do list.
I designed the entire product in Open Design before writing a line of production code — not Figma. The canvas was organized by flow, and within each flow, by artboard. Critically, artboards weren't just per-screen; they covered states of the same screen — logging a normal prayer, logging a Travel-mode combined prayer, logging a prayer that had already passed. That state-first design process is what let the eventual adaptive prayer card handle a dozen-plus real-world cases cleanly instead of accumulating special cases in code.
Scoping was deliberate, not accidental. No iPad — phone is where people's prayer time actually happens, and iPad screenshots would have cost real effort for a form factor that doesn't serve the core habit loop. Quran reading was deferred: it's optional, praying is mandatory, and a full reader is genuinely better suited to a bigger screen anyway. The goal was building the quality habit first, before chasing the fuller Sunnah layer — the bundled Dua library covers the adjacent need well enough for now.
I'll be honest about where this story doesn't have a dramatic turn: there's no single technical war story from the build. The AI-assisted native build was comparatively smooth. That's worth stating plainly rather than manufacturing conflict that wasn't there — the harder story is upstream, in the product and design decisions above.
The garden is the spine of the product: every completed prayer plants a real, identity- bearing flower — newest first, never decaying. Prayer quality isn't a binary checkbox; it's timeliness (on-time is defined as the first third of a prayer's window) plus an optional reflection, and a flower's brightness encodes that quality back visually.
Monetization is a single one-time lifetime purchase, no subscription — and the paywall is shown after the first bloom, once there's already emotional collateral, not before. The free tier is whole and real: all five daily prayers, not a crippled trial.
Screen Guard — an optional feature that pauses distracting apps during prayer windows — went through a real prioritization arc: framed first as "protect you from your apps," then softened to "a gentle pause before adzan," then, later, promoted back into the core onboarding flow because it needed to be shown, not just told about, to land.
The clearest craft artifact in the app is the adaptive prayer card — one component that covers every real state a prayer can be in: passed and unlogged, passed and logged done, passed and logged missed, current, future, Fajr's unique end-time rule, Isha's unique best-time-before rule, Tahajjud's unique best-time-after rule, a user-added Sunnah prayer, a Travel-mode merged prayer, forward-only customization (enabling Sunnah, Care, or Travel mode doesn't retroactively rewrite history), and a guard against gaming the system by logging future prayers early. That's not five screens — it's one screen designed to be honest about how many states a "simple" prayer log actually has.
The structural language of the app is a split between a "top canopy" and a "bottom LightSheet" — canopy gradient → garden → content → translucent glass at 0.40 alpha → transparent tab bar, one shared, DRY component reused across all five tabs. The garden itself persists under that glass on every screen, frosted and always partially visible, instead of being locked behind a dedicated tab the way most gamified apps hide their progress.
Motion and color were chosen to serve the calm/recharge thesis directly, not for decoration: green, tying back to both Islamic visual tradition and to the grass the flowers grow in; serif headings, specifically to avoid the interface reading as sterile-minimalist and losing its soul; a swipe-to-complete gesture instead of a tap, adding deliberate friction so completing a prayer is an intentional act rather than a reflexive button-press; a bloom animation immediately on completion; and haptic feedback across most buttons and the qibla compass, aimed at making the interface feel alive rather than static.
Onboarding is deliberately long — built to feel like a self-discovery quiz rather than a speed-run to the paywall, because the product's whole premise is that the user's relationship to prayer is personal and worth surfacing before asking for anything.
MuslimWise is Swift/SwiftUI with Android parity via Skip Fuse, which transpiles the same SwiftUI codebase to Kotlin/Compose rather than maintaining two UIs. The codebase splits cleanly: a fully portable model layer with no platform dependencies and services behind protocols, and a separate UI layer — roughly 14,000 lines of Swift total, targeting iOS 17+ on Swift 6. Prayer-time math runs on a pure-Swift, offline, numerically verified solar-geometry engine — self-built rather than a wrapped third-party library, because it's load-bearing for the entire product. Cross-platform support runs through protocol boundaries, so iOS-only capabilities like Screen Guard's FamilyControls integration drop silently on Android instead of forcing platform branches through the UI layer.
On AI leverage specifically: AI iterated and explored within direction I set, not the other way around. Two concrete places where that direction mattered — AI would not have arrived at the LightSheet-over-garden layered composition unsteered; left alone it defaults toward flat design. Same for the Care-mode and Travel-mode logic. The prayer-logic edge cases — start and end times, differing calculation methods, best-time windows — were judgment calls I made and directed, not output AI originated on its own.
Coming from no-code tools (Bubble, Webflow, WordPress/Elementor) into native Swift, the actual mental-model break wasn't learning syntax — it was that no-code platforms give everything a visible place: a menu for it, a visual workflow canvas, visible conditional logic, visible design-system components. Code collapses almost all of that into text with no inherent visual surface. I compensated by explicitly asking AI to explain logic back to me, specifically to make sure edge cases weren't silently going uncovered in code I couldn't "see" the way I could in a no-code canvas.
Seventeen locales, solo, were AI-driven but steered deliberately away from literal translation toward contextual meaning. My verification method is honest rather than exhaustive: since Indonesian is my native language, I check Indonesian output first for correct contextual word choice against the English source, and if that lands right, I extend that trust to the other sixteen locales rather than manually reviewing each one.
The actual build rhythm was a closed-loop "cocreation" workflow — planning and debugging crunched up front in focused sessions, with longer task execution scheduled to run independently of active before/after-hours work blocks, which is how a full native, localized, cross-platform-ready app got built solo around a full-time job.
There's no formal growth case study here — the go-to-market plan that exists is designed, not executed. What does exist is early, real, and organic: roughly 100 active users driven entirely by posts to a personal social account with about 1,500 followers, with zero paid marketing spent. One person has already paid for the lifetime plan. People are asking for the Android version before it's out.
More telling than the raw count is what that early group volunteered unprompted: praise for the lock-out mechanic and the depth of Travel and Care modes, plus organic feature suggestions — a weather-aware Friday-to-Dhuhr prayer conversion, treating missed-prayer logs as a "counter" or tracker of Qada prayers owed. People engaged deeply enough with the actual mechanics to propose extensions to them, which is a stronger signal at this stage than a larger but shallower number would be.
Shipping this also taught a lesson that Growth, PM, and Ops roles hadn't: the importance of a clear, explicit "good enough" milestone when entering a category — prayer-reminder apps — that already has established incumbents. Knowing where the line is matters as much as the craft on either side of it.
I'm not going to smooth over the gaps: there's no single dramatic engineering war story to tell here, and the growth plan is real but unrun. What I can say plainly is this — I designed the product decisions, designed the interface myself across every screen state before a line of code existed, then built and shipped it natively, solo, part-time, around a full-time role, using AI as directed execution leverage rather than a tool I deferred to. The early organic traction — people using it, one person paying for it, without any marketing push — is a first, small proof that the judgment behind it was right.
What's next: an Android release via the same Skip Fuse codebase, Sunnah and history features already gated behind the current paywall for later expansion, and the growth plan sitting ready but intentionally not yet triggered.