Built for the Church of Sixty

There is a design principle behind SoapBox that has cost us features, complicated our roadmap, and made several obvious decisions non-obvious. We build for the church of sixty.

Not sixty thousand. Not the multi-site campus with a communications director and a production team. Sixty people in a room on a Sunday, a pastor who is bivocational or close to it, and a building that someone unlocks with an actual key.

Almost all church technology is built for the other church — the large one with a staff directory, an operations director, a line item in the budget for software, and someone whose job description quietly includes “the tech.” That church is a genuinely good customer. It can evaluate a product, run an implementation, train volunteers, and pay for seats. If you are building a business, it is the rational place to point.

It is also not what most congregations look like. The typical congregation in this country is small — much smaller than the one most software imagines. The pastor is frequently also the bookkeeper, the scheduler, the counselor, the person who fixes the thermostat, and the one holding the phone that runs the livestream. There is no IT person. There is no onboarding call, because there is no free hour in which to have one.

It is not the same product with fewer seats

The mistake I see repeatedly — and made myself early — is treating the small church as the large church scaled down. Same product, cheaper tier, fewer users. That framing is comfortable and completely wrong, because the constraint is not budget. It is that nobody is available to operate the software.

Once you actually accept that, it changes the engineering rather than the pricing page.

Roles cannot be required, because one person is every role. Any workflow that assumes an administrator configures a thing so that a different person can use it is dead on arrival; the administrator and the user are the same tired human being on a Tuesday night. Defaults have to be right on the first screen, because nobody is going to configure anything, ever — a settings page is not flexibility to a small church, it is a bill. It has to work entirely on one phone, since there may be no church computer and the pastor's laptop is at home. Setup is measured in minutes, not in a project plan, and if it takes forty minutes it will never be finished, because it will be started twice and abandoned twice and then quietly never mentioned again.

And the empty state has to be the real product. Most software treats the empty state as a brief transitional moment before the customer fills the thing with data. A small church may live in the empty state for months. If your product is only good once there are two hundred members, four groups, and a year of giving history in it, then for most congregations your product is never good.

The asymmetry that makes it a strategy

I want to be honest that this is not purely conviction. There is a hard-headed reason too, and it is the asymmetry that runs in exactly one direction.

Build for the church of sixty, and the church of six thousand still works. It is a little simpler than they might have designed for themselves, and they will ask for more granular permissions, and mostly they are relieved that their volunteers can figure it out without training. Build for six thousand, and the church of sixty cannot use it at all. Not “finds it expensive.” Cannot use it — the first screen asks for an org structure that does not exist there.

Simplicity is portable upward. Complexity is not portable downward, and no amount of tiering fixes that, because you cannot tier away a set of assumptions baked into the data model.

There is a discipline in it as well. A small church is a merciless product reviewer, in the best sense. They have no capacity to absorb your cleverness. If a feature does not obviously help in the first two minutes, it does not get used, and you find out immediately instead of after a six-month implementation that a paid staff member was assigned to make succeed. Every large customer will make a mediocre feature work because someone is being paid to make it work. That is a comfortable way to learn nothing.

What the small church actually protects

The reason I care about this beyond the strategy is simpler. A pastor of sixty is doing the same work as a pastor of six thousand — the visits, the crisis calls, the funerals, the sermon that has to be ready on Sunday regardless of what the week held — with none of the leverage. She is the one for whom an hour returned is a genuinely different week. And she is the least likely to get software built with her in mind, because she is the least attractive customer on every spreadsheet in the category.

So the rule we hold ourselves to is small and testable: could a pastor with no help, no training, and fifteen minutes on a phone get real value out of this today? If the answer requires a call, a video, or a settings page, we have not finished. Sometimes that means shipping less than we would like, and it has meant saying no to features that would demo beautifully to a large church.

The scarcest resource in a small congregation is not money. It is that pastor's attention, and every screen we add spends a little of it. If we are going to ask for any of it, the exchange had better be honest.