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 110 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.

One more order-of-operations rule, and it caused more failed installs than anything after the Safari trap: install first, sign in second. Signing in inside the browser does not sign you in inside the installed app — they are separate on the same phone — so a volunteer who signs in and then installs lands on a login screen and assumes it broke. The guide, the printed card and the app itself now all say the same thing: add it to your home screen, open it from the icon, then sign in. And give Android users Android steps; iPhone instructions on an Android phone read as “this is not for me.”

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, with the blocker at the top — Safari on iPhone, install before you sign in — not below the fold. 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 — and expect the answer to change as the team grows.

What we started with. The team signed in with a shared access code, one per campus, and a leader could change the code and force every signed-in device back to the login screen with one tap. No individual accounts, no passwords to reset, nothing to hand back. For a hundred volunteers who had just struggled through installing the app, that was the right trade: the simplest thing that worked.

Why it stopped fitting. A shared code can be forwarded, and there is no way to know it happened. The only fix is to change the code — which means telling a hundred other people the new one — so in practice it never got changed. A credential you can’t realistically rotate is one you don’t really control. And removing one person meant disturbing everyone, so it didn’t happen promptly. For a safety team’s roster, that’s backwards.

What it moved to. Individual sign-in by email: type your address, a six-digit code arrives, type it in. No password. The app then knows who you are, and what you can see comes from your row in the roster, not from which code you were handed. Stay active and you never see a login screen again; go quiet for three months and you sign in once more. Removing someone is now one change in the roster — their phone drops to the login screen within a minute, nobody else notices. The everyone-out button is still there for the day you need it.

It rolled out leads first, then the whole team, and the shared codes are being retired one campus at a time as the last volunteers move over. Nothing was taken away from anyone until its replacement had been through real Sundays.

The new traps. Individual sign-in brings its own version of the Safari problem. The code email can land in spam while the sender address is new — tell the first volunteers to check junk and mark it “not spam” in their actual mail account, not just the phone app. Send the email from the organisation’s own domain, or a cautious volunteer will read it as phishing, which is the correct instinct. And signing in inside Safari does not sign you in inside the installed app; they’re separate on the same phone. That’s why “sign in with email” has to be a button on the login screen, not a link in a message — an installed app has no address bar.

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 — and plan to outgrow a shared code.
Install first, sign in second — and put that on the card.

See one that was built this way

The volunteer safety app this guide came from is live with a team of more than 110 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 →