The church that also runs a wedding venue
A facility booking, payment and certificate module built as an extension of ChurchCMS — because the client needed one more capability, not a second application to log into.
- SECTOR
- Religious organisations
- TYPE
- Product extension
- BASE PRODUCT
- ChurchCMS
- STACK
- Laravel, MySQL
- STATUS
- LIVE
Extend the product, or build another one
The client was already running ChurchCMS for members, events, sermons and contributions. They then needed something it did not do: manage the halls they rent out, track the money that comes in from them, and produce marriage and baptism certificates.
There are two ways to answer that. Sell them a separate facility booking product, or extend what they already have. The first is easier to deliver and worse to live with — two logins, two member lists, two places a name might be spelled differently, and a volunteer administrator who has to remember which system holds what.
A second application is not an addition. It is a permanent tax on everyone who uses either one.
We built the capability into ChurchCMS instead. Facility bookings, payments, member records and certificates live in the same administrative environment, on the same permission model, with one set of people to maintain. This is what product enhancement means for us in practice: our products are a starting point clients own and extend, not a fixed package they fit themselves around.
Two organisations sharing one office
A church with a wedding hall is running two things at once, and they have almost nothing in common except the people administering both.
Pastoral and community
- Members, families and groups
- Services, events and attendance
- Contributions given freely
- Success measured in participation
- No customers, no invoices
Commercial and contractual
- Customers who may not be members
- Dates, availability and confirmed reservations
- Advances, balances and receipts
- Success measured in utilisation and revenue
- Obligations that must be honoured
Hall income is often what pays for maintenance the congregation's giving does not cover, so it is not a side activity. But church software is written for the left column, and generic venue booking software knows nothing about the right column belonging to a church. The module had to sit across both.
A double booking here is not a refund
In a hotel, two reservations on one date means an apology, a discount and an alternative room. In a community organisation where both families attend the same church and know each other, it means one wedding has nowhere to go and a relationship that does not recover.
That raised the stakes on what is otherwise ordinary calendar logic. Availability is authoritative rather than advisory, conflicting dates cannot be confirmed, and the calendar shows the actual state of every facility rather than one administrator's understanding of it.
Availability is per facility
Halls, community rooms and event spaces are booked independently, so one busy hall does not obscure a free one.
Enquiry is not reservation
A held date and a confirmed booking are different states. Most conflicts arise from treating a verbal enquiry as settled.
Anyone on duty can check
Availability does not depend on the one person who keeps the diary being reachable — which in a volunteer-run office is the usual failure.
Bookings retain their history
Who booked, when it was confirmed and what was agreed remain on the record, so a disputed arrangement can be checked rather than remembered.
Advance, balance, and the gap between them
Hall bookings are almost never paid in one go. An advance secures the date, the balance falls due nearer the event, and the interval can run to months. During that window a booking is confirmed but not fully paid, and that state is where the money goes missing.
Payment is therefore tracked against the reservation rather than as a separate ledger. Each booking carries its agreed amount, what has been received, what remains and when it was paid, with receipts issued from the same record. Facility-wise revenue reporting rolls up from there, so the church can see which spaces actually earn.
The useful figure is outstanding balances across confirmed bookings. On a paper diary that number does not exist anywhere; it has to be reconstructed by going through every entry, which means in practice nobody knows it.
The certificate is the output. The record is the asset.
Marriage and baptism certificates look like a printing task, and treating them that way is the mistake. Someone will ask this church for a copy of a baptism record in thirty years — for a visa application, a marriage in another parish, a genealogical question, or their own child's baptism. Churches are asked for these constantly, and the request is usually decades after the event.
So the module stores structured records first and prints from them second. Marriage records hold bride and groom details, date, church and officiating details. Baptism records hold the baptised person, parents, date, church and officiating minister. Certificates render from templates with that data populated, meaning a reprint years later is a lookup rather than an archaeology exercise in a filing cabinet.
Template-based generation also lets the church keep its own certificate designs without anyone editing a document by hand each time — the same pattern used for the training centre certificates elsewhere in our work.
What the module adds
Building an extension that does not become a fork
The risk with customising a product is ending up with a version that can never take an upstream update again. Avoiding that was an explicit design goal.
Additive, not invasive
The module adds its own entities and screens rather than rewriting existing ChurchCMS behaviour, so the core remains recognisable and updatable.
Shared records where it helps
A booking customer who is also a member links to the existing member record instead of creating a parallel contact database.
Inherits the existing model
ChurchCMS already scopes access per area. Facility administration became another area within it rather than a second permission system.
Template rendering
Certificates generate from stored records, so a new design needs a template rather than a developer.
Same as the base product
Laravel and MySQL, matching ChurchCMS, so anyone who can maintain the product can maintain the extension.
MIT core underneath
ChurchCMS is open source, so the church retains the ability to have this maintained by anyone competent in Laravel.
How the team built it
GegoSoft engineers use Claude Code as standard daily tooling. On an extension the first task is understanding an existing codebase well enough not to damage it, and that is where the tooling earned most — reading the surrounding conventions and matching them, so the new module reads like part of the product rather than something bolted on.
The additive design, the decision to reuse member identity and the certificate record model were the team's. Every change passed normal review before merge.
What changed
Hall availability became checkable by anyone on duty, payment status became visible per booking instead of reconstructed from a diary, and certificates stopped being prepared by hand. The church added a capability without adding a system, which for a volunteer-administered organisation is the part that matters most.
Common questions
Can GegoSoft add custom features to one of your products?
Yes, and it is one of the two things we do most. Our products are a starting point rather than a fixed package — this church needed facility booking and certificates, so we built those into ChurchCMS instead of selling a second application.
Will customisation stop us taking future updates?
Not if the extension is built additively, which is how we approach it. New entities and screens sit alongside the existing product rather than rewriting it, so the core stays updatable. A customisation that forks the product is a maintenance problem you inherit forever.
Can you build a facility or hall booking system for us?
Yes, standalone or as an extension of an existing system. The parts worth getting right are the distinction between a held date and a confirmed booking, and tracking advance against balance — that is where most manual booking processes lose money.
Can the system generate marriage and baptism certificates?
Yes, from stored structured records rather than as one-off documents. That matters because churches are asked to reproduce these records decades later, and a certificate is only as good as the record behind it.
Do we need to use ChurchCMS to get this?
No. The module was built for a ChurchCMS deployment, but facility booking, payment tracking and certificate generation can be built into other systems or delivered standalone.
Need one more thing your current system does not do?
Tell us what you run today and what is missing. Extending something that works is usually cheaper and always easier to live with than adding a second system beside it.
Start a conversation See all case studies