Building Ledenboek: Encoding Dutch Association Governance in Rails

The Netherlands runs on associations. Sports clubs, breed clubs, neighbourhood associations, professional bodies, foundations — hundreds of thousands of them, nearly all administered by volunteers in the evening.

Ledenboek is the member management platform we built for them. The interesting engineering problem was not member records and invoices. It was that a Dutch vereniging is a legal structure with rules about who may do what, and software that ignores those rules is useless to the treasurer who has to answer for the books.

The domain is the difficulty

A first look at this problem suggests straightforward CRUD: members, contributions, invoices, events. Build the tables, add authentication, ship it.

Then you meet the board. A vereniging has officers with defined responsibilities — a voorzitter (chair), a penningmeester (treasurer), a secretaris (secretary) — and those are not decorative titles. They map to real authority over real records. The treasurer may see payment data the general membership may not. The secretary maintains the register. Committees exist alongside the board with their own scopes.

The one that surprised us most is the kascommissie: an audit committee, elected from the membership, that reviews the treasurer’s books and grants decharge — formal discharge of responsibility for the financial year. It is a governance mechanism with a specific sequence. The committee reviews, each member signs, and only when all of them have signed does the treasurer receive discharge.

That is a multi-party approval workflow with legal meaning, and it does not fit an admin flag.

Roles that mean something

Authorisation in Ledenboek is not a boolean. It is a set of roles with genuinely different capabilities, and it has to be understandable by a volunteer who is not going to read documentation.

The kascommissie flow is a good example of why this matters. The committee needs access to financial records for review — but only for review, only for the relevant period, and their signature has to be recorded as an event, not just a state change. When all signatures are collected, the treasurer is notified of discharge automatically.

Getting this right is what makes the software trustworthy to a board that is personally accountable. Getting it wrong means an association cannot use the system for the one thing it most needs to get right.

Payments where the money actually is

Dutch consumers pay by iDEAL. Not by credit card, not by PayPal — iDEAL, through their own bank, and any platform that asks a Dutch association member for card details will see a drop-off that no amount of design fixes.

Ledenboek integrates Mollie for iDEAL, and the important part of that integration is not taking a payment. It is reconciliation: matching an incoming payment to the right member, the right invoice and the right contribution period, then handling everything that does not match cleanly. Partial payments. Someone paying twice. A payment from a spouse’s bank account with a different name on it.

The reconciliation logic is where the treasurer’s time actually goes, so that is where the software has to earn its place. Automatic contribution collection, invoicing and dunning all hang off this.

Multi-tenancy, one association at a time

Each vereniging is a tenant with its own members, roles, financials and communications. The isolation requirement is absolute: association A’s treasurer must never see association B’s member list.

This is the same architecture question we have written about in Rails multi-tenancy strategies and Postgres row-level security, applied to a case where the data is unusually sensitive — membership of an association can reveal political affiliation, health status or religion, all special categories under GDPR.

A boring stack, on purpose

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

There is no frontend framework, and that is a deliberate choice rather than a limitation. The interaction patterns here — forms, tables, filters, wizards — are exactly what Turbo is good at. A member administration screen does not need a client-side router and a state management library; it needs to load fast on a five-year-old laptop in a clubhouse with poor wifi.

Hotwire lets a small team ship a responsive interface without maintaining two applications. For a product whose users are volunteers rather than power users, the page that simply works is worth more than the one with optimistic UI.

We wrote about the Propshaft migration separately; on a greenfield Rails 8 app it is simply the default and one less thing to configure.

Volunteers are the real constraint

Every design decision in Ledenboek is shaped by one fact: the person using it did not choose this job as a career. They were elected at a general meeting, they will hold the role for two or three years, and then they will hand it to somebody else.

That has consequences a normal B2B SaaS does not face.

Onboarding happens repeatedly, forever. There is no admin who learns the system once. Every year, new board members arrive with no training budget and no patience.

The handover is part of the product. When a treasurer steps down, the next one has to pick up mid-year without losing history. Audit trails are not a compliance feature here, they are how the next volunteer figures out what happened.

Support questions arrive at odd hours and usually just before a general meeting.

Designing for that means preferring the obvious flow over the efficient one, keeping destructive actions hard to reach, and making the system explain itself.

What we would tell another team

If you are building software for an institution with formal governance — an association, a foundation, a cooperative, a works council — the temptation is to model the data and treat the rules as permissions bolted on afterwards.

That is backwards. The governance is the domain model. Who may approve what, in what order, with what record of having done so, is the part your users are legally exposed on. Model it first, in the language your users already use, and the CRUD arranges itself around it.

Ledenboek now serves over a hundred associations. What keeps them is not the feature list. It is that the treasurer can hand the books to the kascommissie, get discharge, and have a record of it.

Building software for an organisation with real governance requirements? TTB Software builds Rails platforms where the domain rules are the hard part. Nineteen years of it.