I'm a developer and application security engineer, and an active member of my church. About a year ago my pastor challenged me to use my skills to serve the congregation. I casually mentioned building an app. He didn't just say yes, he told me to turn it into a business.
So I started researching.
What I found:
Most churches are running 4-5 disconnected tools just to operate. One for announcements, one for giving, one for events, maybe a group chat somewhere. The existing platforms are either too expensive, too complicated, or just not built for how churches actually work.
But two problems kept coming up that nobody was really solving.
Problem 1:
Communication across wildly different audiences
A congregation isn't one demographic. Teenagers live on their phones. Middle-aged members check email. Elderly members aren't downloading anything. A push notification reaches maybe 40% of a congregation. The rest never see it.
Problem 2:
Member retention after the first visit
Most churches have no structured answer to what happens after someone walks in for the first time. Someone visits, comes back once or twice, and quietly disappears. There's no clear path that says "here's what's next for you."
Where I went wrong first:
I started building every feature I could think of ( likes, reactions, group chats, games, AI). I got carried away. After a few months I had a feature-rich app that wasn't solving anything real.
I scrapped most of it and rebuilt around those two core problems.
The tech stack:
-React Native + Expo for the mobile app
-Firebase (Firestore, Auth, Storage, Cloud Functions) for the backend
-Multi-tenant architecture (all churches share one Firebase project, isolated by tenant path)
-Custom claims for role-based access control (owner, admin, leader, member)
-Expo EAS for builds and OTA updates
-OpenAI for the church AI assistant
-Expo push notifications + planned Twilio SMS for broadcast
What I built:
A white-label church app platform. Each church gets their own fully branded app: their colors, their logo, their name. The backend is multi-tenant so onboarding a new church is a config file and a build, not weeks of custom work.
For communication: A broadcast system that reaches members through push notifications, SMS, and email. One message from the admin dashboard, three delivery channels, nobody gets left out.
For retention: A customizable faith journey tracker. Admins set up a roadmap of next steps — welcome classes, ministries to join, ways to serve. New members see exactly where they are and what comes next. First-time visitors get a reason to come back and a path to follow when they do.
Everything else — community feed, ministry group chats, events, giving, prayer requests, Bible trivia, and a church AI assistant — lives in one app instead of five different tools.
Where I am now:
My own church is live as the first client
My pastor has connections across multiple churches and is actively making introductions
The app is in TestFlight for iOS, Android build in progress
Waitlist open at https://kinvox.app/
The numbers:
$0 in revenue (pre-revenue, first paying client imminent)
Running costs are minimal at current scale ( Firebase, EAS, and OpenAI are all pay-as-you-go)
Targeting $149/month per church
At 10 churches: ~$1,490 MRR with costs still under $100/month
What I'm still figuring out:
Is $149/month the right price for a small-medium church? Too low? Too high?
SMS broadcasting has a real per-message cost
do churches actually value reaching non-app members or do they assume everyone has a smartphone?
Anyone built in a religious or community niche? if so, what did early go-to-market actually look like?
Happy to go deep on the technical architecture, the multi-tenant Firebase setup, or the go-to-market if anyone's curious.