Loading...
Loading...
Marcus Thiek
Founder, Marcthek
Last year, we partnered with a congregation in Aizawl to replace their paper-based church management system with a full-featured mobile app. This post is a behind-the-scenes look at how we built it, what we learned, and why React Native was the right choice.
The church had over 500 members across multiple cell groups and departments. The administrative team — all volunteers — spent enormous amounts of time every month doing things manually:
These were smart, dedicated people spending their best hours on low-value administrative work. Our job was to give that time back to them.
When the conversation started, the church's technical committee asked whether they needed two separate apps — one for iOS and one for Android. My answer was no.
React Native lets us write JavaScript/TypeScript code that runs natively on both platforms. This has two important benefits for ministry clients:
We used Expo as our development framework, which accelerated the build significantly and gave us access to device APIs (camera for QR codes, push notifications) without native code.
The system had three components:
1. The mobile app (React Native + Expo)
This is what members and staff use daily. Built with:
2. The backend API (Node.js + PostgreSQL)
The church's data lives in a PostgreSQL database on a managed hosting provider. The API is built with Node.js and Express, with Prisma as the ORM. We chose PostgreSQL for its reliability and the ability to do complex relational queries — church data has many relationships (members have families, families belong to cell groups, etc.).
3. The admin web portal (Next.js)
Church administrators access a web portal for reports, bulk data management, and configuration. This shared the same API as the mobile app.
Connectivity in parts of Mizoram can be unreliable. Members in areas with weak signal shouldn't be locked out of the app.
We implemented an offline-first architecture using WatermelonDB — a fast, reactive database for React Native. When the app is online, it syncs with the server. When offline, it continues to work locally and queues any changes for the next sync.
This was the most technically complex part of the project but also the most valuable. The church runs Sunday services regardless of whether the internet works.
After 14 weeks of development, here's what went live:
Start smaller than you think. Our first instinct was to build everything. After the discovery phase, we cut the scope by 30% to focus on the highest-value features. Version 1 launched on time and on budget. Version 2 added the remaining features four months later.
Train for adoption. The best app fails if people don't use it. We ran three training sessions for different staff groups before launch. We also created short video tutorials in Mizo for church members. Adoption reached 80% of the congregation within 6 weeks.
Ministry context matters. Understanding the church's culture, leadership structure, and how decisions are made shaped every design decision. We didn't build a generic church app. We built their church app.
Six months after launch, the administrative team reports saving 20+ hours per month. Monthly attendance reports that used to take a day now take minutes. Leadership can see giving trends for the first time in the church's history.
The most meaningful feedback came from the treasurer: "I used to dread the end of every month. Now I actually look forward to seeing the reports."
That's why we build what we build.
If you lead a church or ministry organization and want to explore what a management system could look like for your context, let's talk. First conversation is always free.
Share this article
Marcus Thiek
Founder & Lead Engineer, Marcthek
Building digital solutions for ministries, organizations, and businesses from Aizawl, Mizoram. Passionate about technology that preserves culture and connects communities.
Weekly insights on tech, digital transformation, and building in Mizoram. No spam — unsubscribe anytime.