Building a church website in Belize that a volunteer can run

I am rebuilding a parish website at the moment, and it has turned into a useful example of what a church website in Belize actually needs. Not a brochure that nobody updates. A working noticeboard: mass times, events, announcements, and a place to keep photographs and video of the things the community did together.

The same shape fits a school, a village council, a sports association or any small organisation where the person updating the site is a volunteer with other responsibilities.

What should a church website in Belize include?

When I sat down with the list of what people actually asked for, it came to five things.

• Mass times and a calendar of events. The single most looked-up piece of information. It has to be correct, and it has to be readable on a phone in bad light.
• Announcements. Short notices that go up and come down again. A death, a change of schedule, a fundraiser.
• A Memories section. Albums of photographs and video from feast days, confirmations, repairs to the building, youth group trips.
• A contact form. So people can write in without exposing a personal email address to spam.
• An admin area a volunteer can run. This is the one that decides whether the site is alive in two years.

Nothing on that list is exotic. What makes it hard is the last point. Most church and community sites in Belize do not die because the design was wrong. They die because the one person who knew how to log in moved away, or the monthly fee stopped being paid, or the plugin that ran the photo gallery broke after an update and nobody knew what to do.

How I am building it

The site is built with Next.js, a framework for building websites that sends finished pages to the browser instead of making the phone assemble them. That matters here. Plenty of people open these pages on a modest phone over mobile data, so pages need to arrive quickly and work without a lot of waiting.

Behind it sits SQLite, a database that lives as a single file on the server. For a site with a few hundred events and a few thousand photographs, that is more than enough, and it makes backups simple: copy the file and the uploads folder and you have the whole site.

There is no hosted content management system, the kind of monthly-fee service that gives you an editor in exchange for a subscription. The admin area is part of the site, written for this organisation, with the vocabulary the organisation actually uses. Not "posts" and "taxonomies". Mass times. Announcements. Albums.

I run it on my own Linux servers, the same ones that carry my other platforms, so there is no monthly CMS bill and the running cost is small and predictable.

Video that plays on a phone

The Memories section took the most thought. Photographs are easy. Video is not.

Someone records a service on an iPhone and sends me a file that a lot of Android phones will refuse to play, in a format that is far larger than it needs to be. So when video is uploaded, the server converts it automatically using ffmpeg, a free open-source tool for processing audio and video. The result is a smaller file in a format every modern phone can play, with a still image pulled from the video to use as the thumbnail.

The volunteer does not have to know any of that. They pick the file from their phone, give the album a name, and wait a moment. The work happens on the server.

Why not just use a hosted website builder?

Sometimes you should. If an organisation needs three pages and a map, and has no photographs to manage, a hosted builder is sensible and I will say so. I would rather not build something you do not need.

Here is the comparison I walk people through.

A hosted builder or CMS makes sense when:

• You need something online this week and the content is simple.
• Nobody in the organisation will ever upload more than a page of text.
• You are comfortable paying a monthly fee indefinitely, in US dollars, by card.
• You do not mind that the site lives inside somebody else's product.

A built site makes sense when:

• The admin has to be simple enough for a rotating volunteer, which usually means it has to be made for your specific tasks rather than general purpose.
• You are handling media at volume: albums, video, years of accumulated photographs.
• The monthly fee is a real problem for the budget, or payment depends on one person's card.
• You want to own the code and be able to hand it to somebody else later.

Everything I build is delivered with the source code, written documentation and help text inside the application itself. The organisation owns it. If I am unavailable, another developer can pick it up and read what is there. That is not generosity, it is the only arrangement that makes sense for a committee that changes every few years. The same principle runs through all of my services.

Who runs the site after the volunteer changes?

This is the question I ask first, and most people have not thought about it.

The answer has three parts. First, the admin area only contains tasks this organisation performs, so there is little to learn and little to get wrong. Second, there is help text on the screen where the work is done, not in a manual in a drawer. Third, accounts are separate, so a new secretary gets her own login and the old one is switched off without anybody sharing a password.

I learned most of this building school systems. Scholar, my school management platform, is live with a Belizean school, and schools have exactly the same problem: the person entering data in August may not be the person entering it in January. Software for small organisations has to assume staff turnover rather than hope against it.

What it involves on your side

Less than people expect, but not nothing.

I need the content: current mass or meeting times, a short description of the organisation, contact details, and a starting batch of photographs. I need one person named as the decision maker, so that feedback arrives as one voice rather than six. And I need an hour or two from whoever will run the admin, once it is ready, to walk through it with me.

A site of this size is a matter of a few weeks rather than months, with the first working version up early so you can look at real pages instead of drawings.

Where to start

1. Write down the three things people phone or message you to ask. That is your home page.
2. Name the person who will update the site, and ask them honestly how much time they have each month.
3. Gather the photographs and video that are currently scattered across phones and WhatsApp groups. Decide what belongs in public.
4. Check what you pay now for hosting, domains and any subscriptions, and who holds those accounts.
5. Decide whether a simple hosted page is enough. If it is, use one.

If after that you still think you need something built, write to me through the contact page and tell me what your organisation does and who will be looking after the site.