Behind the Scenes
How we manage members through our website: registration, resolutions and the libro soci
Why we built the tools ourselves
An associazione di promozione sociale — an APS, the Italian legal form for
social-promotion associations — doesn't run on events. It runs on
obligations: a well-kept libro soci (the members' register that Italian
third-sector law requires), numbered resolutions, dues collected and
tracked, insured volunteers, logged hours. For years we handled these things
with spreadsheets and shared folders, and every time we needed a figure for a
grant application or for our accountant, the hunt for the right file would
start all over again.
Today associative life runs through the site you're reading. It isn't
off-the-shelf management software adapted to fit: it's software we wrote
ourselves, built on the rules of our own statuto (bylaws) and of the
Codice del Terzo Settore, Italy's Third Sector Code. This article tells you
how it really works, without embellishment.
Registration: the membership card is issued when the fee is collected
Anyone who wants to join starts from the "Become a member" page. The site
shows whichever membership campaign is open at that moment, with the
categories and fees set by the assembly. You fill in your details, choose
your category, and pay by card.
The technical point that matters is when the membership card comes into
being: **at the moment payment is collected, not when the form is
submitted**. Before payment we record a pending position; it's the payment
confirmation that triggers the creation of the actual card. If the browser
closes during payment, or the connection drops at the wrong moment, the card
is still created once the payment lands. No one is left having paid with no
card to show for it.
Each card is assigned a progressive number per campaign, in the form
`year/progressive`, and a cryptographically signed QR code. The QR code is
for us at the door: scan it and you know immediately whether that card is
valid, with no phone calls and no printed lists.
For minors there's an extra rule, one the bylaws require: the countersignature
of whoever holds parental responsibility is needed. The system doesn't let
you skip it: if the category is the minors' category and the countersignature
is missing, the application doesn't go through.
People who sign up at the desk, in cash, follow the same path: the only
difference is that whoever is on the till enters the details, and the
parent's countersignature is collected on paper.
The resolution: admission is an act of the board, not a payment
Here's the step that most management software gets wrong, and that for an
APS is actually the heart of the whole thing.
Paying the fee does not make you a member. It makes you the holder of a
card pending ratification. It is the consiglio direttivo — the board — that
admits a person, by resolution (delibera), within thirty days. Until that
happens, the person holds a card but doesn't have membership rights: they
can't vote at the assembly.
The site mirrors this distinction exactly. The board finds the list of
pending cards, reviews them as a batch, and resolves. Ratification is
all-or-nothing on the batch and is tied to an existing resolution: you can't
"admit someone" without the act that formally provides for it.
If the board rejects an application, no line appears in the libro soci, the
card is cancelled and the QR code revoked. The fee is not refunded: that's a
choice we made deliberately, and it's written into our regulations — not an
oversight in the software.
The libro soci: entries are added, never corrected
The libro soci is an append-only register. Four kinds of events go into it:
admission, re-admission, cessation and rectification. No one can go back and
rewrite a line: a correction is a new line that cites the previous one and
explains what's being corrected.
There are two practical consequences of this choice.
The first is that card expiry and arrears do not enter the libro soci.
They're administrative states of the card, not facts resolved by the board:
mixing them in would make the register unreadable exactly when it matters
most — in front of an audit.
The second is that nobody writes into the libro soci by hand. Lines are
generated by the acts themselves: when the board ratifies an admission, the
line appears. If for any reason the write to the register fails, the
membership operation fails too — we'd rather have an operation that stops
than a register that tells a different story from the facts.
Every member, from their own private area, can consult the libro soci as
required by Article 15 of the Codice del Terzo Settore. They see four
columns: register number, admission date, surname and first name, cessation
date. Fiscal code, date of birth, reason for leaving and card number never
leave the server: the right to consult the register is not a right to know
the personal data of other members.
Volunteers: hours only count if someone logs them
The volunteer register is kept separate from the members' registry, because
the two things don't overlap: you can be a volunteer without being a member,
and vice versa.
For every volunteer we hold their personal details, their insurance status
and their shifts. The system warns us if a volunteer shows as active but
uninsured — that's the obligation under Article 18 of the *Codice del Terzo
Settore*, and it's not something to discover after an injury. The register
exports to CSV and PDF whenever it needs to be produced.
On shifts we made a cautious choice. When a till or bar shift opens during an
event, the system tries to link it automatically to the right volunteer. If
there's more than one possible match, it assigns nothing and leaves a
trace of the ambiguity. Attributing hours to the wrong person is worse than
not attributing them at all: volunteer hours end up in financial statements
and grant applications.
What a member sees when they log in
The private area isn't a showcase: it's the place where a member finds what's
theirs. The virtual membership card with its QR code, generated on their own
device. The history of past years' cards and the fee receipt. The *libro
soci* in its permitted view. Assembly minutes and votes on motions. Chat with
other members. Export of their own data and account deletion, because GDPR
isn't a banner you click to accept.
What still isn't right
It would be convenient to say everything is in order. It isn't.
The signing of resolutions isn't a strong signature yet: the second factor is
in place but not actually validated. Until it is, the signature counts as
internal tracking, not as a cryptographic guarantee, and that needs saying.
The progressive numbering of resolutions doesn't run through a database
sequence: two resolutions created at the exact same instant could collide.
At our volumes it has never happened, but it's a known flaw, not a risk we've
ruled out.
Finally, there's an old membership-request flow, predating the current one,
that sends an email to the board and goes nowhere: no one can approve those
requests from the site. It's still reachable and needs to be removed.
We write these things down here because an association that publishes its
own financial statements can also publish its own technical debts. And
because the surest way never to fix them is to pretend they don't exist.
