Launch to Your Congregation and Keep It Running

The launch that reached forty people

A church spends six weeks building an app. It's announced once from the front, a QR code goes in the bulletin, and about forty of the four hundred regular attenders install it. Six months later those forty are still using it and nobody else has joined.

The build was fine. The rollout was one announcement, aimed at the people who were already going to say yes.

This module is about the other three hundred and sixty, and about the weekly habit that determines whether any of this is still true next year.

Launch to the middle, not the enthusiasts

Early adopters need no persuading — they'll find it from a single mention. Your rollout should be designed for the person who is mildly interested, not confident with new apps, and easily stopped by one moment of friction.

That means announcing more than once, in more than one way, over several weeks. Once is an event; repeated is a rollout. Expect to feel like you are over-communicating at roughly the point where it starts to work.

It also means removing the friction you can't see. Sit with two people while they install it and say nothing. Where they hesitate is your actual onboarding problem, and it is never where you assumed.

A QR code on the screen for thirty seconds while people are still finding their seats will not do it. On the bulletin they take home, in an email with a direct link, and shown slowly enough that a phone can actually focus — that will.

Give people a reason that exists this week

"Download our app" is not a reason. "The sign-up sheet for the Christmas meal is in the app" is. Adoption follows content people actually want, and it stalls where the app is a container for nothing in particular.

So put something in it worth opening before you promote it. A sermon series everyone's following, the rota, the giving link, this week's schedule. Whatever your congregation currently asks the office about by phone is the right candidate — that's demonstrated demand.

One deliberate move that works: put something in the app first, once, and say so. Not permanently — a church that hides everything behind an app punishes the people least equipped to use it. But one week where the schedule appeared there first gives the mildly-interested a concrete reason to install.

Bring your people in, don't wait for them

If your directory already exists — a spreadsheet, a database, a paper list — import it rather than waiting for four hundred people to type their own details in. Most platforms take a spreadsheet upload and offer a preview step that flags duplicates before anything is written.

Clean the data before you import, because import is when everyone discovers the list has three versions of the same family. And be thoughtful about what you bring across: a directory that exists for the church office is not automatically a directory the whole congregation should browse. Check what will be visible to members before you upload, not after.

Tell people you're doing it. Discovering that your address is in a new app that you never entered it into is a small betrayal, and entirely avoidable with one sentence in an announcement.

The weekly rhythm that keeps it alive

Everything above is a launch. This part is why it survives.

Fifteen minutes, once a week, attached to something that already happens — the staff meeting, the Monday morning routine. In that time: update this week's events, check nothing is advertising something that already happened, glance at giving, and clear anything that needs a response. That's it.

Name the person who does it. Not the team, not the pastor by default. One name, with a realistic amount of time, and a second person who knows how in case the first is away — the same resilience argument as the very first Build module, applied to the ongoing work rather than the account.

Then review the whole thing twice a year against a single question: is this still worth the fifteen minutes? Tools that stopped earning their keep should be retired deliberately rather than left to rot in public, which is how a church ends up with an app advertising a Christmas service in June.

Your exercise

Write your rollout on one page before you announce anything: the three moments you'll tell people, the one thing that will be in the app worth opening, and the name of the person doing the weekly fifteen minutes. If you can't fill in the third, fix that before you launch — an unmaintained rollout is worse than a delayed one.

Then find two people who are not confident with technology and watch them install it without helping. Whatever stops them is the real work, and you will not have guessed it.