Web developer in Leipzig for associations and nonprofits

Why association websites get stuck

If one volunteer set up your website, it probably still runs on that person’s accounts. Often the domain is registered in a private name and the hosting is paid from a private card.

Plugin updates then happen when someone remembers them. Membership applications and event registrations pile up in the WordPress database, next to the admin accounts that attackers look for. A paid theme does not protect a site: Patchstack found that 76 percent of the vulnerabilities in paid plugins and themes could be exploited in real attacks (Patchstack, February 2026). When the volunteer leaves the association, nobody can log in to fix any of it.

What changes after the move

Pages, news and events become a static site: the public server holds finished HTML files, with no login and no database behind them. Forms send their entries to a form service or a small backend, and the association decides how long entries are kept. Donations run through the page of your donation or payment provider, so donor data stays with the provider.

People ask AI assistants where they can volunteer in Leipzig or which club in Halle has a youth team. An assistant can name your association when your offers, dates and meeting places stand as text on your pages. On the new site they do, and structured data states the association’s name, the area it serves and its contact page.

A member area with logins is the one part that needs a database. It runs on Symfony or Laravel next to the static pages, and the assessment shows whether your members use it enough to keep it.

The handover sheet for your board

The sheet lists what an association should hold in its own name. I fill it in with you at the handover, and you can use it today to check your current site.

1. Domain: registered to the association, with two board members who can log in to the registrar.
2. Server or hosting contract: in the association’s name, paid from its account.
3. Code and content: in a repository the association owns, with at least two people who have access.
4. Accounts for the site: one per person, no shared passwords.
5. Forms: the service that receives membership applications and registrations, and how long it keeps them.
6. Donations: the provider account, and who sees donor data.
7. Newsletter: the provider, the subscriber list and where each consent is recorded.
8. Imprint and privacy notice: who is named in them, and who updates them when the board changes.
9. Backups: where they are stored, and who has restored one at least once.
10. Publishing: who may publish a page, and who approves it.

Who I am

I am Michael Wutzke, an IT architect for data platforms in Frankfurt with more than twenty years in IT and media. From 2017 to January 2024 I was editor in chief of an information portal that many contributors write for and that reached more than one million readers a year by January 2024. I hold a training authorization from IHK Frankfurt for two IT apprenticeships and teach at Claude Hacker House. I build software with Claude and Codex and am interested in open-source AI models that an association can run on a server of its own. I have documented and implemented the protective measures the GDPR requires. Details: Background.