A community site that maintains itself

The problem

The children's and youth work at Åbenkirke Odense had no page of its own. What people actually needed to know — what this is, when it runs, and whether it is a safe place to send a child — was scattered across the church's own site, Facebook posts and whatever people remembered to pass on.

Membership is also the association's lifeline. Public funding follows the members registered against the correct local association, and sign-up happens in the national self-service system, where the list runs to 25 of them. Choose the wrong one and the money goes to another city.

What I built

The site is static. No CMS, no database, no login to keep patched — an association run by volunteers should not inherit a server that needs looking after. It builds to files and is published on Azure Static Web Apps.

The calendar syncs itself. Every build pulls the church's Google Calendar as ICS, expands the recurrence rules into concrete dates, and lets only the children's and youth activities through. A nightly rebuild means a new date in the church calendar is on the site the next morning without anyone touching it.

There is no analytics and there are no cookies, and the fonts are served from the site’s own domain rather than from Google. When the audience is minors, the most responsible way to handle visitor data is not to collect it.

The design had to carry two identities at once: the national association's young, high-contrast look and the church's warmer tone. The weight sits with the association in what you see first, and with the church in the body copy.

Alongside the site sits a digital expense form for the volunteers. It is a React app where an Azure Function renders the claim as a PDF and files it in the treasurer's Dropbox, so receipts are no longer photos in a message thread.

Where it stands

The site is live at akbuodense.dk and approved by the national association, which supplied the links that pre-select Odense during sign-up — so the funding lands where it should.

It is tested from 320 to 1440 px and passes an accessibility audit against WCAG 2.1 AA with no violations. Mobile was not a later adjustment; it is how the audience actually opens the site.