Guide · Volunteer operations

How to get an app onto a hundred volunteers’ phones

Building the app is the easy part. Getting it installed on a hundred phones belonging to people who are not paid, not technical, and not in the room is the part that decides whether it works.

I built a safety app for a church team of more than a hundred volunteers across three campuses. The build took weeks. Installation took longer to get right than several features did, and it was the only part where failure was silent — a volunteer who cannot install it does not file a bug report. They just show up on Sunday without it and say nothing.

This is what I learned, in the order it will matter to you.

Skip the app store

For an internal tool used by one organisation, the app stores cost you more than they give you. You need an Apple developer account at $99 a year, a Google Play account, a review process measured in days, two codebases or a cross-platform framework, and a new review every time you fix a typo. Then every volunteer has to find your app among the millions in a store, and remember an Apple ID password they set in 2019.

The alternative is a web app that installs to the phone’s home screen. The volunteer opens a link, follows two or three taps, and ends up with an icon that looks and behaves like any other app. Full screen, no browser bar, works offline. No store, no review, no per-seat fee, and you ship a fix by pushing to your site.

The trade is real and worth stating: you do not get deep hardware access, and on iPhone the install path is not obvious. The rest of this guide is mostly about that second problem.

The iPhone trap that will break your rollout

If a volunteer’s default browser is Chrome, they cannot install your app

On iPhone, Add to Home Screen exists only in Safari. If someone has set Chrome, Firefox, Edge or DuckDuckGo as their default browser, your link opens there — and the option simply is not in the menu. Not greyed out. Not hidden behind a submenu. Absent.

They will look for it, not find it, decide they did something wrong, and give up without telling you. This was the single largest source of failed installs in our rollout, and we only found it by testing on other people’s real phones.

The fix is to detect it and say so. The app checks whether it is running in Safari on iOS, and if it is not, it shows a short message: open this link in Safari to install it, with the steps. That one screen turned a silent failure into a ten-second correction.

If you build nothing else from this guide, build that.

The install steps, written for people who are not technical

Write these out per platform and hand them over. Do not write “install the PWA.” Nobody outside software knows what that means.

iPhone and iPad

Open the link in Safari. If it opens in another browser, copy the link and paste it into Safari.
Tap the Share button — the square with an arrow coming out of the top, at the bottom of the screen.
Scroll down the list and tap Add to Home Screen.
Tap Add. The icon appears on the home screen. Open it from there from now on, not from the browser.

Android

Open the link in Chrome.
Tap the three dots in the top right.
Tap Install app, or Add to Home screen depending on the phone.
Confirm. The icon appears with the rest of the apps.

Two details that save support messages. Tell people the icon is the thing to open from now on, because a surprising number will keep going back to the browser and wonder why it feels different. And tell them roughly what the icon looks like, because on a crowded home screen people cannot find what they just added.

Hand it over three ways, not one

A hundred volunteers is a hundred chances for “I couldn’t figure it out.” Assume every single channel will be missed by someone.

What we actually used

A link, sent in whatever channel the team already reads. Not a new channel — the one they already use.
A one-page guide with the exact steps for each phone type, in plain language, with pictures of the buttons.
A printed card in the room where the team meets. This mattered more than expected. People install things when they are standing around before a meeting, not when they are at home reading a message.

Then get five minutes at the start of a team meeting and walk the room through it together. Ten people installing it at once, with someone who can look at the screen of whoever is stuck, beats fifty individual messages.

Test it on other people’s phones, not yours

Your phone is the worst possible test device. It has the app cached, the right browser, and a developer’s tolerance for weirdness. Borrow phones. An old Android, an iPhone with Chrome set as default, one with the text size cranked up, one that is nearly out of storage.

Two tests worth running every single time:

Airplane mode. Turn it on and open the app from the home screen icon. If the content people need in an emergency does not appear, it is not finished. Large buildings eat cell signal, and the moment somebody needs the bleeding-control steps is not the moment to watch a loading spinner.
A genuinely cold install. New phone, never visited the site, following only the written guide with nobody helping. If they get stuck, the guide is wrong, not the person.

“A volunteer who cannot install it does not file a bug report. They just show up without it.”

Plan for people leaving before anyone leaves

Volunteer teams turn over constantly, and an app on a personal phone is not something you can collect back at the door. Decide up front how access ends.

What worked for us: the team signs in with a shared access code rather than individual passwords, and a leader can change that code and force every signed-in device back to the login screen with one tap. Phones sitting idle in someone’s pocket drop out the next time they are opened. No IT ticket, no chasing, nothing to hand back.

Shared codes are a deliberate trade. They are far easier for a hundred volunteers than a hundred accounts, and the security model has to account for that — which is why anything genuinely sensitive should sit behind a role check on the server, not just behind the login screen.

What this costs to run

Close to nothing, at this size. A web app installed to the home screen has no app store fees, no per-seat licences, and no separate iPhone and Android versions to maintain. Adding a second and third campus was configuration, not a rebuild. The bill for hosting and the database sits inside free tiers for a team of this size.

That matters for volunteer organisations specifically, because per-seat pricing punishes exactly the thing you want — more people having the information.

The short version

Use a web app installed to the home screen. Skip the app stores.
Detect non-Safari browsers on iPhone and tell people what to do. This is the one that silently breaks rollouts.
Write the steps per platform, in plain language, with pictures.
Send a link, print a card, and walk a room through it together.
Test in airplane mode and on someone else’s phone, every time.
Decide how access ends before anyone leaves.

See one that was built this way

The volunteer safety app this guide came from is live with a team of more than a hundred across three campuses. There is a working demo loaded with invented data — nothing in it belongs to a real person or a real team.

Read the case study →