Ledenboek bouwen: verenigingsbestuur vastleggen in Rails

Nederland draait op verenigingen. Sportclubs, rasverenigingen, buurtverenigingen, beroepsorganisaties, stichtingen — honderdduizenden, vrijwel allemaal bestuurd door vrijwilligers in de avonduren.

Ledenboek is het ledenadministratieplatform dat we voor hen bouwden. Het interessante technische probleem was niet het bijhouden van leden en facturen. Het was dat een vereniging een rechtsvorm is met regels over wie wat mag, en dat software die die regels negeert waardeloos is voor de penningmeester die zich over de boeken moet verantwoorden.

Het domein is de moeilijkheid

Op het eerste gezicht lijkt dit rechttoe rechtaan CRUD: leden, contributies, facturen, activiteiten. Tabellen bouwen, authenticatie eromheen, klaar.

Dan ontmoet je het bestuur. Een vereniging heeft functionarissen met omschreven verantwoordelijkheden — een voorzitter, een penningmeester, een secretaris — en dat zijn geen decoratieve titels. Ze staan voor werkelijke zeggenschap over werkelijke gegevens. De penningmeester mag betaalgegevens zien die de gewone leden niet mogen zien. De secretaris beheert het register. Naast het bestuur bestaan commissies met hun eigen bereik.

Wat ons het meest verraste is de kascommissie: een uit de leden gekozen commissie die de boeken van de penningmeester controleert en decharge verleent — formele ontheffing van verantwoordelijkheid over het boekjaar. Het is een bestuursmechanisme met een vaste volgorde. De commissie beoordeelt, elk lid tekent, en pas als iedereen getekend heeft krijgt de penningmeester decharge.

Dat is een goedkeuringsproces met meerdere partijen en juridische betekenis, en het past niet in een adminvlaggetje.

Rollen die iets betekenen

Autorisatie in Ledenboek is geen boolean. Het is een verzameling rollen met wezenlijk verschillende bevoegdheden, en het moet begrijpelijk zijn voor een vrijwilliger die geen documentatie gaat lezen.

De kascommissieflow laat goed zien waarom dat telt. De commissie heeft toegang tot financiële stukken nodig voor de controle — maar alleen voor de controle, alleen over de betreffende periode, en hun handtekening moet als gebeurtenis worden vastgelegd, niet slechts als statuswijziging. Zijn alle handtekeningen binnen, dan wordt de penningmeester automatisch van de decharge op de hoogte gesteld.

Dit goed krijgen is wat de software betrouwbaar maakt voor een bestuur dat persoonlijk aansprakelijk is. Dit fout krijgen betekent dat een vereniging het systeem niet kan gebruiken voor juist datgene wat het meest goed moet gaan.

Betalen waar het geld werkelijk zit

Nederlandse consumenten betalen met iDEAL. Niet met creditcard, niet met PayPal — met iDEAL, via hun eigen bank. Elk platform dat een Nederlands verenigingslid om kaartgegevens vraagt, ziet een uitval die met geen enkel ontwerp te repareren valt.

Ledenboek integreert Mollie voor iDEAL, en het belangrijkste aan die integratie is niet het aannemen van een betaling. Het is de afstemming: een binnenkomende betaling koppelen aan het juiste lid, de juiste factuur en de juiste contributieperiode — en vervolgens alles afhandelen wat niet netjes matcht. Deelbetalingen. Iemand die twee keer betaalt. Een betaling vanaf de rekening van een partner met een andere naam erop.

In die afstemmingslogica gaat de tijd van de penningmeester werkelijk zitten, dus daar moet de software zijn plaats verdienen. Automatische contributie-inning, facturatie en herinneringen hangen hier allemaal aan.

Multi-tenancy, één vereniging tegelijk

Elke vereniging is een tenant met eigen leden, rollen, financiën en communicatie. De eis van isolatie is absoluut: de penningmeester van vereniging A mag de ledenlijst van vereniging B nooit zien.

Dat is dezelfde architectuurvraag als in multi-tenancy-strategieën voor Rails en row-level security in Postgres, toegepast op een geval waarin de gegevens uitzonderlijk gevoelig zijn — lidmaatschap van een vereniging kan politieke voorkeur, gezondheid of religie prijsgeven, allemaal bijzondere categorieën onder de AVG.

Een saaie stack, met opzet

Rails 8, Ruby 3.4, PostgreSQL, Hotwire (Turbo en Stimulus), Tailwind, Propshaft, Devise, Puma.

Er is geen frontendframework, en dat is een keuze en geen beperking. De interactiepatronen hier — formulieren, tabellen, filters, wizards — zijn precies waar Turbo goed in is. Een ledenadministratiescherm heeft geen client-side router en state management nodig; het moet snel laden op een vijf jaar oude laptop in een clubhuis met matige wifi.

Met Hotwire levert een klein team een responsieve interface zonder twee applicaties te onderhouden. Voor een product waarvan de gebruikers vrijwilligers zijn en geen power users, is de pagina die het gewoon doet meer waard dan die met optimistische UI.

Over de Propshaft-migratie schreven we apart; op een nieuwe Rails 8-app is het simpelweg de standaard en één ding minder om in te richten.

Vrijwilligers zijn de echte randvoorwaarde

Elke ontwerpkeuze in Ledenboek wordt bepaald door één gegeven: degene die het gebruikt heeft dit niet als loopbaan gekozen. Diegene is gekozen op een algemene ledenvergadering, houdt de rol twee of drie jaar, en draagt hem dan over.

Dat heeft gevolgen die een gewone B2B-SaaS niet kent.

Onboarding gebeurt eindeloos opnieuw. Er is geen beheerder die het systeem één keer leert. Elk jaar komen er nieuwe bestuursleden zonder opleidingsbudget en zonder geduld.

De overdracht is onderdeel van het product. Stopt een penningmeester, dan moet de volgende halverwege het jaar instappen zonder historie te verliezen. Audit trails zijn hier geen compliancefeature maar de manier waarop de volgende vrijwilliger uitzoekt wat er gebeurd is.

Supportvragen komen op rare tijden en meestal net vóór een ledenvergadering.

Daarvoor ontwerpen betekent de voor de hand liggende flow verkiezen boven de efficiënte, destructieve acties moeilijk bereikbaar houden, en het systeem zichzelf laten uitleggen.

Wat we een ander team zouden meegeven

Bouw je software voor een instelling met formeel bestuur — een vereniging, een stichting, een coöperatie, een ondernemingsraad — dan is de verleiding om de data te modelleren en de regels achteraf als rechten erop te schroeven.

Dat is andersom. Het bestuur is het domeinmodel. Wie wat mag goedkeuren, in welke volgorde, met welke vastlegging daarvan, is precies waar je gebruikers juridisch op aanspreekbaar zijn. Modelleer dat eerst, in de taal die je gebruikers al spreken, en de CRUD schikt zich er vanzelf omheen.

Ledenboek bedient inmiddels ruim honderd verenigingen. Wat hen bindt is niet de featurelijst. Het is dat de penningmeester de boeken aan de kascommissie kan overdragen, decharge krijgt, en daar een vastlegging van heeft.

Software nodig voor een organisatie met echte bestuursvereisten? TTB Software bouwt Rails-platformen waar de domeinregels het moeilijke deel zijn. Al negentien jaar.