A church management app is a household record with rules about who can open it.
Most of what a church management app has to do is unglamorous: one record per person, those people linked into households, a note of who turned up, and a rule about who is allowed to look. The last one carries the most weight, because a congregation database holds children, guardians, allergies and family circumstances next to the phone numbers. Money is usually kept apart for the same reason, which is why church giving apps tend to sit in their own system with their own permissions.
This page covers the record shape a congregation management app actually needs, what children in the database mean for access control, how check-in behaves in a room with no signal, and what building your own gets you that renting one does not.
See who should see which fieldThe short version
The records are the easy part: deciding who can open them is not.
A church management app is four things stacked on each other: a person record, a household that links people together, an attendance or check-in record, and a set of roles that decides who can read what. The first two decide whether your numbers are true. The fourth decides whether a bad morning stays a bad morning.
Serving schedules, group lists, messaging and follow up all hang off those four. Most small churches do not need more features. They need those four to be correct, and to work on a phone in the building.
Children and families decide who gets a login
A congregation record is not a mailing list. It links a child to guardians, names the adults who may collect that child, carries an allergy note, and sometimes carries the reason a family stopped coming. So access control is a feature with its own screens and its own tests, not an admin setting you will get to later.
There is a written rule to design against. Article 9 of the GDPR prohibits processing personal data revealing religious or philosophical beliefs. It then carves out a not-for-profit body with a religious aim, acting in the course of its legitimate activities with appropriate safeguards, on two conditions: the processing relates solely to members, former members or people in regular contact with the body in connection with its purposes, and the data are not disclosed outside that body without the consent of the people concerned. Read that as a design brief. A church database is special category data by default, and a directory export is a disclosure.
In the United States no single federal statute says the same thing to a church, and it is worth saying so plainly. COPPA covers online services that collect personal information from children under 13, so it usually does not bite when staff type a child's details into a back office record. It does bite the moment you add a login that under 13s use themselves. Either way the bar does not move: it comes from your safeguarding policy and your insurer, and they expect what the GDPR condition expects, which is that as few people as possible can open a child record.
The shape that works is four roles and a default of no. Office staff see everything. A group leader sees the adults in their own group. A checked volunteer sees the children in their room for that session, with the allergy note and the list of adults who may collect them. A member sees only what other members chose to publish. Pastoral notes live in a separate table with a separate permission, because a note that everyone with a login can read is a note nobody will write honestly.
Regulation (EU) 2016/679, Article 9, special categories of personal data
Try it
Who can open which field
Pick a role, then read down the record. Anything not listed for a role should be invisible to it, not greyed out.
Adult name and photo
only if that adult published it
Adult phone and address
a leader sees their own group only
Child first name and room
for this session only
Allergy and medical note
the volunteer in that room needs it
Who may collect the child
matched against the pickup code
Pastoral note
separate table, separate permission
Member sees 1 of these 6 fields. A login that can open a child record it does not need is the failure everyone remembers.
One person, one household, one record
The field list is short and every field earns its place. Legal name and the name people actually use. A household link and the person's place in it, adult or child. Date of birth, because rooms and groups are age graded and because a 12 year old and a 17 year old are different problems. Contact details on adults. Guardians and pickup permissions on children. Allergy and medical note. A photo consent flag, set per person, checked before any picture is used. Status: visitor, regular, member, moved away.
Households are not tidy families and the model has to accept that. Two parents at separate addresses, both linked to the same child. Four students in one house who are not related. A grandparent in the same household as a grandchild. If you put one address on a person and call the job done, you will be maintaining duplicate records inside a month.
Duplicates are the other unglamorous requirement. A visitor card filled in twice, a nickname on one record and a full name on the other, and the attendance count is wrong from then on. Merging two records while keeping both histories is a feature you build on purpose. So is keeping money in its own place: gifts belong in a donation tracking app rather than as a column on the person record, because the people who need the pastoral view and the people who need the finance view are rarely the same people.
Check-in has to work in a basement with no signal
Children's check-in is a physical process with a software shadow. A guardian arrives, finds their household, checks in two children and gets a code. A tag with the same code goes on each child. Nobody hands a child back without the matching code. The software exists so that the two codes match and the room knows who is expected.
Two things break it. The first is the network. The room with the toddlers is usually the room with the worst signal, and a station that cannot write locally and sync later will fail on the one morning it matters. Generate codes on the device, queue the writes, reconcile afterwards, and accept that two stations working offline at once can issue the same code unless the code carries something specific to the device.
The second is the printer, and this is where the plan meets hardware. Printing from a React Native and Expo app goes through the platform print services: the Expo print module sends HTML or a PDF to the native print dialog, uses AirPrint on iOS, and offers printer selection on iOS only. A network label printer that AirPrint supports will work. A USB thermal printer that needs its vendor SDK will not, without native code. Plenty of churches print nothing and write the code on a plain sticker, which is a legitimate answer, and cheaper to settle before buying hardware.
The follow up afterwards is a separate job with separate consent. A first time visitor gets one message from a person, not a newsletter subscription, and that is the work a church texting app does.
What a full platform does, and where it stops
Established church management systems are good software and an honest page says so. Planning Center, Breeze and Rock RMS between them cover giving, check-in with label printers, groups, background check workflows and mass messaging. They charge monthly, they charge differently from each other, and the details change, so read the current pricing page rather than any summary of it, including this one.
They stop at the rule that belongs only to you. Two congregations sharing one volunteer pool and needing separate directories. A serving rule that nobody may be scheduled in two rooms in the same hour. A deacon fund where a request is visible to exactly two people. A membership class or a sacrament record your tradition keeps and nobody else does. A platform answers those with a custom field and a convention everybody forgets.
That is the real decision. If your rules are the ordinary ones, rent the platform and spend the saved weekend on people. If one rule matters enough that you keep working around it every week, the workaround is the thing worth building, and it is much smaller than a whole ChMS app.
What each approach gives a church office
| Option | Household linked records | Check-in with pickup codes | Role based access | Works with no signal |
|---|---|---|---|---|
| Spreadsheet and a group chat | No | No | No | only if the file is local |
| Paper sign-in sheet | No | written by hand | No | Yes |
| Full ChMS platform | Yes | Yes | Yes | varies by product |
| Airtable or Notion as the database | Yes | you build it | by table, not per record | not reliably |
| An app you build yourself | Yes | Yes | Yes | with a local queue |
Building one around your own congregation
Start from the thing you currently do by hand. For most churches it is one of three: the serving schedule nobody can see on a phone, the check-in queue at 10:25, or the fact that one person is the only one who knows who has not been seen for a month. Build that one thing properly, with the permission rules in from the start, and leave the rest where it is.
Newly is an AI app builder. You describe the app in plain English, including who may see which field, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. iOS goes out through TestFlight and App Store Connect on your own Apple Developer account, there are no built-in payments, so giving still runs through a provider, and the code comes out one way with the CLI, npm i -g @newly/cli then newly pull. It is not a church management system and it will not arrive knowing your tradition.
One decision comes before any screen: where the member records live. The role rules you wrote down have to be enforced by the database itself, not by which button the app hides, because an app that hides a field has usually already downloaded it.
Questions people ask about church management apps
It is the record system for a congregation: one record per person, people linked into households, attendance or check-in, groups and serving schedules, and roles that decide who can see what. Giving is often a separate system with separate permissions. The mobile version matters because most of the people using it are standing in a building, not sitting at a desk.
Write down who may open what, then build that
List your roles, decide what each one may see on a person record, and start with the one job your church still does on paper every Sunday.
Start building