Church Management Software: Build or Buy at Your Campus Count

When is off the shelf genuinely the right call here?

Most churches should buy, and the honest cut off is not a feeling. If you run a single campus under roughly 600 weekend attendance, your annual giving is under about $1.5 million, and you employ fewer than eight full time staff, buy. Breeze ChMS at its flat rate is a genuinely good product for that church and you will not beat it for the money. Planning Center at two or three modules is a fair deal and a well built system. Pair either with Tithe.ly or Pushpay for giving, configure it properly, and spend the difference on people rather than software.

Buy also when your pain is configuration debt rather than architecture. Most frustration with packaged church software comes from workflows nobody has set up, custom fields nobody agreed on, and a check-in process that three volunteers each run differently. A consultant who knows Planning Center inside out costs a fraction of a build and fixes that in a fortnight. Ask yourself plainly whether the tool cannot represent your church, or whether nobody has sat down and told it what your church looks like. Those are different problems with very different price tags.

And buy while you are still growing fast. A church adding a campus a year does not yet have a stable operating model worth encoding in software. Packaged tools flex badly, but they flex. A build encodes decisions, and encoding decisions you are about to change is the most expensive mistake in this category. Wait until the shape of your Sunday has held steady for a year.

When does a custom build actually pay off?

The threshold is three campuses, but the real trigger is what the third campus does to your data. Campus in most church management products is a tag on a person rather than a dimension with its own permissions, budgets and staff hierarchy. At one site that is invisible. At three it means transfers overwrite history, a campus pastor either sees everyone's giving or nobody's, and every cross campus report starts with an export.

Count the signals. You employ someone whose real job description includes exporting and reconciling. Your executive pastor asks a cross system question, say what happened to giving among families who joined a group in the last 18 months, and gets an answer in weeks rather than minutes. You have bought a fourth tool specifically to bridge two others. Your church management stack has crossed $40,000 a year and is priced on active people count, meaning the software bill grows exactly when the church grows. Three of those and a build is defensible.

One signal is sufficient on its own: a genuine near miss on volunteer clearance. Planning Center Check-Ins and Services will schedule anyone you put on the list. Background check status is a field, not a blocking condition, so a volunteer whose Ministry Safe clearance expired eighteen months ago stays on the Sunday rotation until somebody notices. A custom scheduler can refuse to publish that rotation. If you have already had the conversation where nobody could prove every volunteer working with minors last quarter was cleared, you have your answer.

The money case is smaller than people expect and still adds up. Three campuses at three hours a week of hand matching names between a check-in export and a giving batch, at a loaded staff cost near $32 an hour, is roughly $15,000 a year of reconciliation before a single guest is contacted.

How do they compare on the things that matter in this industry?

The person record. Planning Center is built as separate products sharing a People directory. That is a sound design for a 300 person church and a ceiling past three campuses, because a household is not a folder, it is a set of relationships with dates on them. Pushpay and Tithe.ly are payments companies first: their person record exists to attach a card to a name, and neither will ever be your system of record for pastoral care. A build lets you model one person with many identities, email, phone, card token, check-in code, app device, resolved by a matching service with a confidence score and a human review queue.

Giving and pastoral data. Packaged tools keep these apart by construction, partly for card compliance and partly because pastoral staff seeing gift amounts is a board level question in most churches. The vendor answer is a CSV export. A build keeps the wall and moves it: card data stays with a tokenising processor so you remain in the lightest Payment Card Industry Data Security Standard scope, gift facts land against a resolved household, and role based masking decides who sees a band, a figure or nothing at all.

Fund accounting. A single online gift split across building, benevolence and general is one transaction to your giving platform and three restricted entries to QuickBooks or Shelby. Processing fees land at transaction level while funds are tracked at designation level, which is why that reconciliation is off by an unexplainable amount every month. Configuration will not fix that. Designation splits modelled at the gift line, with fees allocated proportionally, will.

Reporting rigidity. Packaged workflows fire on one event inside one module. They cannot reason across checked in twice, gave once, joined no group, then nothing for six weeks, because that sentence spans four systems.

What does total cost of ownership look like at your scale?

Three build shapes recur. The narrow build, meaning the household graph plus giving ingestion from your existing processor, is $40,000 to $75,000 in 8 to 12 weeks. The focused first release adds role masked giving views with an audit log per view and the guest follow up engine, at $60,000 to $130,000 in 12 to 16 weeks. The full platform adds kids check-in with kiosk hardware, volunteer scheduling with clearance gating, groups, fund accounting integration and a member app, at $150,000 to $400,000 phased over 6 to 12 months. Those are Digital Heroes delivery bands, not a market survey.

Running costs are 15 to 18 percent of the build per year. For a $126,000 first release that is roughly $19,000 to $23,000, covering $250 to $900 a month in hosting plus a change retainer. Two costs do not disappear: payment processing continues unchanged because you kept your processor, and any Planning Center modules you retain keep renewing. A build on top reduces module count rather than eliminating the subscription line, so put it in the board pack that way.

The line that decides the budget is migration. Twenty years of history across a Fellowship One export, an ACS export and a decade of spreadsheets runs 20 to 30 percent of the total, and it is discovered rather than estimated. One clean recent export drops that to 10 to 15 percent. Nothing else in this category moves the number as much.

Against that, price your current stack honestly. Add every per module subscription across church management, giving, communications and the app. Note which of them price on active people count. Then add the reconciliation labour that exists only because none of them join up, because that number appears on no invoice.

What does the hybrid look like, and when is it the honest answer?

This is what we recommend most often, and it is not a compromise. Keep Planning Center for services and check-in, where it is strong. Keep Pushpay or Tithe.ly for the payment rails you already trust. Build the thin layer neither of them will ever give you: one household graph with identity resolution, campus as a dated dimension so a transfer is an event rather than an overwrite, and the follow up engine that turns Sunday connection cards into tasks by Sunday evening rather than Thursday.

That is the $40,000 to $75,000 narrow build, or $60,000 to $130,000 once you add masked giving views and follow up. It sits alongside what you run today, pulls from the Planning Center interface, and ingests gift facts from your processor. Rip and replace becomes a year two decision made with data instead of frustration, and most churches that take this path never make it, because the pain they were feeling was the join, not the tools.

Two practical notes. Build a reconciliation job rather than trusting the giving feed, because feeds lag and batches occasionally do not arrive. A nightly comparison that flags a missing batch costs very little and prevents a month end you cannot explain. And prove identity resolution on the campus with the messiest data first. If fuzzy matching on name, phone, address and household membership holds up there it holds up everywhere, and you will have tuned the confidence threshold twice before it touches the other sites.

The hybrid is the honest answer whenever the packaged tools are doing their jobs well and only the space between them is failing. That describes most multi campus churches we talk to.

Which should you choose, by operator size and stage?

Single campus, under 600 weekend attendance, under $1.5 million giving. Buy. Breeze ChMS, or Planning Center at two or three modules, configured properly. Anyone recommending a custom build at this size is selling something.

Single campus, 600 to 1,500, growing. Buy, and spend on configuration. Add modules deliberately rather than by default, and start writing down what your operating model actually is, because that document is the discovery input if you ever do build.

Two campuses, stable. Buy, but start measuring. Time the Monday reconciliation. Log how long cross system questions take to answer. If the second campus runs the same playbook as the first, packaged tools will hold. If it is a different congregation with different giving norms and a different service structure, you are closer to the three campus problem than headcount suggests.

Three or more campuses. Hybrid. Narrow build on top of what you have, proven on the messiest campus, then decide. This is where the $40,000 to $75,000 spend does the most work per pound.

Multi campus above roughly 4,000 weekend attendance with seven figure giving. Focused first release at $60,000 to $130,000, then phase check-in and clearance gating once a full giving month has reconciled cleanly against the general ledger. Do not attempt the full platform in one swing.

Whatever you choose, settle ownership before kickoff. You should hold the repository, the data and the cloud accounts from day one rather than at final payment, and you should ask what leaving in year three costs.

If you would rather someone argued with your brief than agreed with it, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. The document is yours whichever way you go.