Case study · Operations app

Over 110 volunteers. Three campuses. One app that works when the Wi-Fi doesn’t.

A church safety team had its procedures spread across binders, group texts and a scheduling tool. Now every member carries the whole thing on their phone — and it works with no signal at all.

A custom app for a multi-campus church safety team — post assignments, emergency procedures, alerts, incident reports and volunteer certification tracking, on every volunteer’s phone, working with or without signal.

Client A multiple campus church in North CarolinaType Internal operations appStatus Live, in weekly use

See it for yourself

A working demo of the real app, loaded with invented data. Nothing in it belongs to a real person or a real team.

Pick a role on the sign-in screen — team member, lead or admin. No password, no email.

Open the live demo →

Emergency dialling and emailing are switched off in the demo; filing a report builds the signed PDF in your browser instead. The procedures and post sheets are placeholders — the real ones belong to the team. Try it on your phone — that is what it was built for.

Why a church safety team outgrows binders and group texts

The safety team covers three campuses across several services every weekend. Volunteers were already scheduled in a rostering tool, but scheduling only answers the first question. The harder ones came up in the moment:

What am I responsible for here?

Every post has different duties, and they lived in a printed binder.

What do we do if…?

Removal, lockdown, evacuation — procedures known best by whoever had been there longest.

Who am I watching for?

Shared in a group text somebody had already scrolled past.

Is my CPR still current?

Tracked in a spreadsheet nobody opened between renewals.

New volunteers shadowed an experienced member and learned by osmosis. And the people who most needed the answers — someone standing at a door, mid-service, phone in hand — were the furthest from them. Teams turn over, too. Every departure took some of that knowledge with it.

What the church safety team app does

A single app the whole team opens from their phone’s home screen. What each person can see is governed by their role — seven of them, named to match the church’s written policy word for word, so the app and the policy use the same words for the same people.

Post assignments

Every position at every campus, with its own duties, shared procedures, and what to do in a lockdown or evacuation.

Alerts

Leaders post a person or vehicle to watch for, with a threat level; anything urgent notifies leads within seconds. Notifications are deliberately non-identifying — they land on lock screens. Details stay behind the login.

Emergency procedures

CPR and AED, choking, severe bleeding, missing child. Step by step, two taps away, readable with no signal, with the church’s full policy attached.

Incident reports

Filed from a phone while details are fresh, with up to four photos. Sent as a signed PDF — logo, policy reference, confidentiality line — emailed automatically to that campus’s list, and kept as a searchable log. Corrections are dated amendments; the original never changes.

Training status

Who is current, who is expiring, who has lapsed — visible to leaders without asking anyone, with reminders sent automatically as expiry dates approach.

No-trespass register

Warnings recorded with the reason, the scope, the date and which police agency was notified, with lapsed warnings flagged — because a warning nobody told the police about is not enforceable.

Sign in as yourself

Email address, six-digit code, no password. Sessions last while you stay active. Leads see who has signed in and who hasn’t, and a sign-in log answers “who had access that Sunday.”

Roster, recruiting and audit trail

A QR-code invitation for recruiting, new-member requests that fold into the roster, lookup into the church’s existing people system instead of retyping, and a log of who changed what, who signed in and who was emailed a report.

Per-campus everything

Each campus has its own posts, address, team and report recipients. Anyone who serves at more than one site switches between them; everyone else sees only their own.

Page one of an incident report PDF generated by the demo app
Page one of a report, generated by the demo. Logo, report reference, who filed it, the policy it was written to, a confidentiality line on every page — and the AMENDED flag, because this one was corrected after it was sent. Invented incident, invented people.

Tracking volunteer certifications without a spreadsheet

Most volunteer teams track CPR, first aid and background checks in a spreadsheet somebody updates once a year. Nobody opens it in between, so the first time a lapsed certification surfaces is usually an audit — or an incident.

Here the certification status sits next to the roster. A leader opens one screen and sees who is current, who expires this quarter, and who has already lapsed, per campus, without asking anyone. New volunteers show up as incomplete until their training is recorded, so onboarding gaps are visible instead of assumed.

Three decisions that made it work on real phones

It works with no signal

Large buildings eat cell service, and the moment you need the bleeding-control steps is not the moment to watch a spinner. The app installs to the home screen and keeps its reference content on the device. Airplane mode is part of the test, every time.

Getting it installed was treated as its own problem

A hundred volunteers is a hundred chances for “I couldn’t figure it out.” They get a link, a guide with the exact steps for their phone, and a printed card in the meeting room. One discovery from testing on real phones: members whose default browser isn’t Safari cannot install a web app on iPhone — the option simply doesn’t appear. The app now detects that and tells them what to do, instead of failing silently.

Access ends in the roster, not in a code change

At launch the team signed in with a shared code, and when someone left, a leader changed the code and tapped a button: every signed-in device — including phones sitting idle in a pocket — dropped back to the login screen. For a hundred people who had just struggled through installing the app, that was the right trade.

As the team passed a hundred across three campuses, the shared code stopped fitting. It can be forwarded, and changing it means telling everyone, so in practice it didn’t get changed. The app now uses individual email sign-in: type your address, a six-digit code arrives, type it in. No password. What each person sees comes from their row in the roster, so taking someone off the roster removes their access — one change, one place — and their phone drops to the sign-in screen within a minute while nobody else notices. The everyone-out button is still there for the day it is needed. The one tap became the blunt instrument, not the everyday tool.

How we got it onto a hundred phones

The rollout was harder than several of the features. I wrote up the whole method — why we skipped the app store, the exact install steps per platform, the iPhone default-browser trap that silently breaks rollouts, and what to test before you hand it to anyone.

Read the install guide →

What changed

  • Every volunteer has the full procedures on them at every service, instead of the subset they happened to remember.
  • A new member gets the same information as a ten-year veteran on day one.
  • Leaders can see training status and post coverage without chasing anyone.
  • An incident report leaves the building as a signed PDF, emailed automatically to the people the policy says must be told — not a screen print somebody meant to attach.
  • Removing someone’s access is one change in the roster. Nobody else notices, and nothing has to be collected back.

“Works with no signal — because the moment you need it is the moment the Wi-Fi doesn’t.”

What “works offline” actually means →

How the app was built, and what it costs to run

A single self-contained web app, with a database behind it for the roster, alerts, training records, incident log and audit trail. It installs to a phone home screen like a native app — no app store, no install fees, and no separate iPhone and Android versions to maintain.

Running cost is close to nothing at this size, and there are no per-seat licences to add up as the team grows. Adding the second and third campus was configuration, not a rebuild.

Your people’s information stays private

A safety team’s roster is sensitive by nature — who is on it, where they stand, what they are trained to do. The app treats it that way. Everything lives in a private database that can only be reached after sign-in; nothing is readable from the page itself, and the most sensitive details are visible to leaders only, not the whole team. Notifications never carry a name, because they land on lock screens.

Before anything goes live, I review the build for exposed data. And nothing about a client — names, screenshots, details — appears on this site without their say-so, which is why this page has no church name and the demo is full of invented people.

Where else a volunteer team app like this fits

The same pattern suits any organisation with a large volunteer or frontline team that needs the same information in everyone’s hands:

  • Other churches and multi-site ministries
  • Event and venue staffing
  • Volunteer fire and rescue
  • School safety teams
  • Retail district operations

Got a team carrying a binder?

Thirty minutes, no charge, no deck. We look at where the time goes and whether there is something here worth building.

Book a free 30-minute call Tell me about your project