We have built several church and ministry websites, and the requirements look similar every time even though the churches differ: a public site with sermons, events and a gallery; a giving page; a contact form; and, the part that is easy to underestimate, an admin panel simple enough that non-technical staff can keep the site updated after we hand it over. This case study shares what we learned about the admin side, bilingual content, mobile uploads and handover.
The admin panel is the real product
A church website that looks good on launch day but goes stale within a month, because only the developer can update it, has failed at its job. So a large share of build time goes into the admin side rather than the public pages:
- Create, edit and delete screens for gallery photos, sermons and events, replacing placeholder content.
- A settings page for contact and giving details.
- A messages panel so contact-form submissions land somewhere staff will actually see them, instead of an inbox nobody checks.
Small details matter more than they should. On one project the admin login form had white text on a white input background, invisible unless you selected it, so staff assumed the form was broken. That kind of bug damages adoption more than a missing feature.
Bilingual content without duplicating the site
Supporting English and Amharic, and in some cases Oromiffa, means more than running text through a translator once. Sermon titles, event descriptions and leadership bios must be editable in each language from the same admin screen, so a staff member updating an event does not need separate technical knowledge to update its translation.
We store each translatable field as a small object per language, for example { "en": "...", "am": "..." }, rather than maintaining separate pages per language, which would double the maintenance burden. The public page picks the visitor's language and falls back to English if a translation is missing. For the front-end side, see Designing for Amharic.
Mobile uploads are a bigger deal than they sound
Most admin users manage the site from a phone, uploading event photos or a new hero image right after a service. That exposed a real bug: uploads that worked from a desktop browser failed from mobile. We traced it to PHP upload directives in .htaccess that needed adjusting for the file sizes and request patterns mobile browsers send. Phone cameras produce large images, so it also helps to resize images in the browser before upload and to show clear progress and error messages.
# .htaccess: allow typical phone photos
php_value upload_max_filesize 12M
php_value post_max_size 16M
php_value max_execution_time 120Some hosts ignore these directives or use different settings, so confirm the values in your host's PHP settings panel as well. "It works on my machine" is a much lower bar than "it works on the device our users have in their hands."
Giving pages
Churches usually receive giving through several channels and for several purposes. We build the giving page as admin-managed data, with accounts that can be added, labelled and reordered without a developer, and with clear instructions in each language. The design principles are covered in Accepting TeleBirr and CBE Birr on a Website.
Choosing the stack
We have used both Firebase and PHP on these projects, depending on hosting and the team that will maintain the site. A static front-end with Firebase fits when the church already has simple hosting and needs live-editable content. A PHP and database setup fits when the host includes it and the church prefers predictable, local billing. See Firebase or MySQL? and our static Next.js guide.
Handover that lasts
- Train the people who will actually use the admin, ideally on their own phones.
- Write a one-page guide with screenshots for the five most common tasks.
- Hand over accounts properly: domain, hosting and admin logins should belong to the organisation, not the developer.
- Set up backups and show a staff member where they are.
- Agree a support arrangement so there is someone to ask after launch.
What we would tell another church starting this process
Budget more thought for who will maintain the site day to day than for the launch design. A beautiful site with a confusing or broken admin experience will look outdated within months. A simpler site with an admin panel your staff enjoy using will keep improving long after the initial build.