Prayer is the most universal spiritual practice on earth. Billions do it daily across every faith tradition. But it is almost entirely invisible. You cannot see who is praying for you. You cannot know that someone across the world just lifted your name. The whole practice exists in isolation.

PrayerMap was born from a simple question: what if you could make the invisible visible? What if prayer had a real-time map, and you could watch connection lines form between strangers across oceans? Not a social media play. Not monetization. A pure non-profit ministry tool.

What started as that question became a 6-platform application with augmented reality, real-time voice channels, a native Apple Watch companion app, and a 6-dashboard admin command center.

The decision to use Expo SDK 54 with React Native 0.81 and React 19.1. Bleeding edge on purpose. For a solo developer, the new architecture (Fabric renderer, TurboModules, bridgeless mode) means fewer native module headaches and faster iteration. The tradeoff is being first to hit undocumented bugs. Worth it, every time.

Supabase runs the entire backend. Postgres + PostGIS for geospatial queries that power the living map. Auth for multi-provider login (Apple, Google, email). 47 Edge Functions handling everything from prayer submission to moderation callbacks. Realtime subscriptions for live presence and group chat. Storage for audio recordings, video prayers, and profile media. One platform, zero infrastructure management.

198 database migrations. That number tells a story. It does not mean the schema was wrong 198 times. It means the data model got better 198 times. Solo development without a deadline means the freedom to refactor when you learn something new. Every migration is a lesson encoded in SQL.

The 3-tier AI behavior monitoring engine: client-side rules running at sub-50ms for immediate content filtering, edge functions for mid-tier analysis (spam detection, pattern matching, abuse scoring), and deep AI pipelines for complex pattern detection across user behavior over time. Three layers because no single layer is fast enough and thorough enough at the same time.

Solo mobile dev shipping is a different beast from web. App Store review, code signing, provisioning profiles, TestFlight distribution, device-specific crashes that only reproduce on hardware you do not own. These are real barriers that teach a discipline web deployment cannot. Every rejected build is a lesson in reading Apple's guidelines like a lawyer.

Building for 6 platforms simultaneously forces you to think in abstractions. You cannot hardcode anything. The custom Expo config plugin for watchOS was not a fun weekend project. It was weeks of reverse-engineering Xcode build phases, understanding how React Native's Metro bundler interacts with native targets, and writing 764 lines of JavaScript that modify the .xcodeproj at prebuild time. The kind of work that has no tutorial.

The hardest part was not the code. It was scope discipline on a project with no paying customers and no deadline. Ministry work has to be its own motivation. 198 migrations means 198 times the thought "this isn't good enough yet." That is either obsession or dedication, and the line between them is whether you eventually ship. Build 148 is in the App Store. That is the answer.

Non-profit does not mean non-professional. The admin system, the moderation pipeline, the behavior monitoring: these exist because real people will use this to share their most vulnerable moments. Someone will post a prayer about a dying parent. Someone will share their addiction recovery. The engineering has to be worthy of that trust. Every Edge Function, every RLS policy, every moderation layer is a promise that their vulnerability will be protected.