Nobody should have to find their own church in a list.

The list of forty churches

Picture the announcement. It is a good announcement. Get the app, all the information is there, we will stop killing so many trees.

Now picture what actually happens on the sofa that afternoon.

She finds it, downloads it, opens it, and is asked to create an account. Then she is asked to find her church. There is a search box. She types the name she has always called it, which is not the name on the incorporation papers, and gets nothing. She tries the town instead, and now there are forty churches, four of which have almost the same name as hers, and one of them is the church that split off in the nineties.

She picks one. It might be the right one. She will not mention this to anybody, because she has decided the problem is her.

And here is the part that should bother a pastor more than the rest of it: she was already a member. She was not looking for a church. She had been to yours for three decades, and the software still made her prove she could find it.

The church should already be known before the sign-in

There is a design decision underneath all of this, and it is upstream of every screen.

You can build a member app one of two ways. You can build a general-purpose app that any person downloads and then uses to search a directory of churches, or you can build one where the church is established first and the person second.

The first way is easier to build, and it is why so many products do it. It is also what produces the sofa scene, and once that first screen exists you cannot design your way out of it. Every welcome, every logo, every friendly line of copy is downstream of a question the member should never have been asked.

The second way says the church is known before authentication. The member arrives through something that already identifies it: a personal link sent to them by name, a code on the bulletin, a QR code on the lobby wall. By the time they are typing anything, the app already knows where they belong, and it can say so on the very first screen, with the church's own name and logo on it.

The difference sounds small when you describe it and it is enormous in the hand. In the first version, a member's opening experience is a test. In the second, it is a welcome.

What “branded” honestly means, and what it does not

This is the section where somebody has to be straight with you, so it may as well be us.

When a church-software company says branded church app, it can mean two entirely different things, and the gap between them is a serious budget line and several months of somebody’s work.

The expensive meaning is a separate application, published under your church's name, with your icon on the home screen and your church findable in the app stores. That is a real thing and a real project: your own developer accounts with Apple and Google, your own review process, and a new submission every time anything ships. It is somebody's ongoing job, and any company offering it should be able to tell you exactly what it costs and who does the releases.

The ordinary meaning, which is what nearly everyone is actually selling, is that members download the vendor's app and your church's identity lives inside it. Your logo, your colors, your name, and ideally a home screen you arranged yourself.

The second one is genuinely good, and it is what most churches want once they understand the trade. What is not fine is a vendor letting you believe you are getting the first when you are getting the second. The way that discovery usually happens is that a member searches the app store for the church by name, finds nothing, and asks the pastor about it in the lobby.

So ask the question flatly and write down the answer: if my member opens the app store and searches my church's name, what do they find? Anyone who answers that plainly is a company you can trust on harder questions later.

Write it once, or write it twice and watch them disagree

Most churches end up publishing the same handful of facts in three or four places. What time the service starts. Where to park. What is happening this Saturday. The address.

They live on the website, in the app, on a printed bulletin, and in whatever the office manager keeps in a document. And they drift, because there is no moment when anybody sits down and reconciles them.

The failure this produces is specific, and it is always the same one. A visitor checks the website, which somebody has kept current, and arrives at the old service time, which is still in the app because that is a separate system with a separate person who was never told.

The fix is not discipline and it is not a checklist. It is that the page should exist once and appear in more than one place. You write the welcome once and choose whether it shows up in the app, on the website, or both. There is one copy, so there is nothing to reconcile, because there is no second version to be wrong.

The same idea handles the things that change on their own. A visitor should be able to see what is coming up without anyone retyping the events, because you already entered them when you set the events up.

Be realistic about how far this goes, though. Some things genuinely are two facts: the way you describe your staff to a stranger on the internet is not the way you list them internally, and that is not a bug. What should never be two facts is anything a visitor uses to decide when to arrive.

A published site should be a photograph, not a window

One more, and it is technical for two paragraphs, but it decides how much your website can hurt you.

There are two ways to put a church's information on the public internet. The site can query your live database every time a stranger loads a page, or the site can be rendered once into plain frozen pages that get served to everybody.

The second is better for a church, and not mainly for speed. It is better because the public internet never touches the database at all. There is no query for anyone to interfere with, so a mistake in a permission rule cannot become a stranger reading your directory. Your members' information is not behind a lock on the front page; it is in a different building.

It has a second benefit that matters on a Saturday night. Publishing becomes an event with a before and an after rather than a live wire. You can look at what you built, publish it deliberately, and if it is wrong, put the previous version back.

The cost of this approach is the honest one to know going in: what is on the internet is what you published, not what is in your database right now. Change something and it goes live when you publish, not the instant you save it.