150 churches, one question, one screen

The right answer was smaller than the brief looked

A ministry coordinating more than 150 churches sounds like a substantial system. Church network, contributions, multiple payment modes, historical reporting — there is an obvious version of this quote with a lot of software in it, and we build church management software, so we could have sold that.

But the administrators were not struggling with accounting. They were struggling with a single recurring question that a spreadsheet answers badly: which churches have not sent their contribution for this period, and who needs chasing.

Everything else in the brief was a consequence of not being able to answer that one thing quickly.

So we built the smallest application that answers it properly, and stopped. No general ledger, no chart of accounts, no reconciliation module. Ministry workers who are volunteers rather than accountants had to be able to use it without training, and that ruled out most of what a bigger system would have added.

The unit is the period, not the payment

A spreadsheet records transactions — a row each time money arrives. That is the wrong shape for this problem, because the ministry's question is never about a transaction. It is always about an absence.

The system instead models the intersection: for each church, in each reporting period, there is an expected contribution and a state. Paid, partly paid, pending, late. A payment fills in a cell that already existed rather than creating a new row.

That inversion is why non-payers are visible at all. In a transaction list, a church that has not paid produces no row and therefore no signal — you find it by comparing a list of payments against a list of churches, by hand, every month. In a period-by-church grid the gap is the most obvious thing on the screen.

Designing for how the money actually arrives

From record-keeping to seeing a trend

The reporting side does one thing the spreadsheets never did: compare. Month against previous month, year against previous year, church against its own history.

That changes what the data is for. A church whose contribution has fallen steadily over six months is telling the ministry something — about its congregation, its circumstances, or its leadership — that a single month's figure cannot. Consistent lateness is a different signal from a sudden gap.

A spreadsheet holds all of that history and surfaces none of it, because nobody has time to build the comparison by hand across 150 rows every month.

How the team built it

GegoSoft engineers use Claude Code as standard daily tooling. On a build this size the effect is simply that it was quick to deliver — which is the difference between a small tool being economical to commission and the client being told the minimum engagement is larger than their problem.

That matters more than it sounds. Plenty of useful small applications never get built because the cost of a bespoke build has traditionally started well above what a focused tool is worth.

What changed

The monthly cross-checking exercise disappeared. Administrators open the current period, see which churches are outstanding, and follow up from the same screen. Comparison reporting gave the ministry something it had never had — a view of whether contributions across the network were rising or falling, and which churches were moving in which direction.

Common questions