Church Websites in Ethiopia: Firebase, PHP, and Two Languages
We've built several church and ministry websites now, and the requirements tend to look similar every time even though the churches themselves are very different: a public-facing site with sermons, events, and a gallery; a giving page; a contact form; and — this is the part that's easy to underestimate — an admin panel simple enough that non-technical staff can actually keep it updated after we hand the project off.
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 actual job. So a large share of the build time on these projects goes into the admin side, not the public pages: CRUD screens for gallery photos, sermons, and events that were previously placeholder content; a settings page for contact and giving details; and 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 sound like they should here. On one project, the admin login form had white text on a white input background — invisible unless you knew to select the text — which meant staff assumed the form was broken. That kind of bug does more damage to adoption than a missing feature would.
Bilingual content without duplicating the whole site
Supporting English and Amharic (and in some cases Oromiffa) well means more than running text through a translator once. Content — sermon titles, event descriptions, leadership bios — needs to be editable in each language independently from the same admin screen, so a staff member updating an event doesn't need separate technical knowledge to update its Amharic version too. We handle this by storing each translatable field as a small object per language in Firestore, rather than maintaining entirely separate pages per language, which would double the maintenance burden for content editors.
Mobile uploads are a bigger deal than they sound
Most admin users on these projects manage the site from a phone, not a laptop — uploading event photos or a new hero slideshow image directly after a service, for example. That surfaced a real bug: uploads that worked fine from a desktop browser were failing from mobile, traced back to PHP upload directives in .htaccess that needed adjusting for the file sizes and request patterns mobile browsers actually send. It's a reminder that "it works on my machine" is a much lower bar than "it works on the actual device our users have in their hands."
What we'd tell another church starting this process
Budget more thought for who will maintain the site day-to-day than for the initial launch design. A beautiful site with a confusing or broken admin experience will look outdated within a few months. A simpler site with an admin panel your staff actually enjoys using will keep improving on its own long after the initial build is done.