KLPKT runs three services a week, multiple midweek groups, a large youth ministry, and a giving program that had been living in a combination of M-Pesa till numbers, paper records, and a WhatsApp broadcast list. The brief was simple — one app that replaces all of it. What made it hard was the shape of the community using it.
The constraint that drove every decision
Most members of the church open the app on budget Android phones over uneven data. Anything that assumed a fast, consistent connection was going to fail for the majority of users. That single constraint decided the whole architecture.
- React Native, because a two-platform build was non-negotiable and the team ships faster in one codebase.
- Firebase for auth, Firestore, and Cloud Functions — so the church's admin team could manage content from a web dashboard without us in the loop.
- HLS for live streaming so a spotty connection degrades gracefully instead of stalling.
- Push notifications over email because email reach in the target community is low; push reach is near-total.
What shipped in v1
Sermons archive with offline download, live service streaming, event RSVPs, daily devotionals, community chat, and M-Pesa-backed giving. Giving was the part we most carefully designed — the receipt path ends in a shareable confirmation screen the giver can forward to family, which turned out to be more important than any other feature we measured.
What we'd do differently
The admin web dashboard started as an afterthought and ended up being what the church staff use more than the app itself. If we rebuilt today, we'd design the staff UI first and the member app second. Churches don't have IT teams — whoever updates the website is also the person printing the bulletin.
