IDMS

Most member-led organisations — associations, societies, clubs, cooperatives — are held together by four things: a WhatsApp group, a spreadsheet of members, a folder of PDFs, and one person who remembers everything. It works until that person is busy.

IDMS puts all of it in one place. A member directory with roles and history. Meetings with agendas, attendance and minutes, including recurring ones. Votes that are genuinely anonymous. Documents with real access rules. Financial records, dues and expenses. Announcements. And an analytics view over exported WhatsApp conversations, so leadership can see what the community is actually talking about instead of guessing.

The stakes here are trust. When a member can't tell whether a vote was counted fairly, or whether the treasurer's numbers match the bank, the organisation stops being a body and becomes a rumour mill. Nothing else it does matters much after that.

So the point of IDMS isn't convenience, though it is convenient. It's that decisions become checkable. A vote produces a result anyone can see and nobody can trace back to a person. Money has a record. Documents have a stated audience. The organisation can hand itself over to the next committee without a handover meeting that lasts three hours.

The plan was a sprint document: four sprints, numbered user stories, each with its own acceptance criteria. Sprint one was the foundation — auth, roles, members. Sprint two was the operating layer: meetings, documents, announcements. Sprint three was the sensitive part: voting and financials. Sprint four was the intelligence layer and the automated jobs.

A few decisions were locked before any code, because they're expensive to change later. Roles live in their own table and are checked through a security-definer function, never read off a profile row — role-on-profile is how privilege escalation happens. Document access is enforced twice, once at the API and once at the storage layer, so a leaked file path is still a locked file. And anonymity in voting had to be structural rather than promised.

What I deliberately left out of v1: payments, a mobile app, and anything resembling a social feed. The organisation already has WhatsApp for talking. IDMS is for the record.

Voting was the piece I spent the most thought on. A ballot row carries no user id at all. A separate token table records only that a given member has voted in a given poll — never how. Both writes happen inside one security-definer function, in one transaction, so the two facts can't drift apart and there's no path, not even a direct database query by an admin, that links a person to a choice. The cost is that you can't 'fix' a mistaken vote, which felt like the right trade.

Member import was the least glamorous and most valuable feature. Real organisations arrive with a messy spreadsheet: duplicate emails, three spellings of the same name, empty phone columns. The importer parses, flags duplicates against existing records, and lets you fix rows inline before anything is committed, rather than failing the whole file on row 47.

Meetings needed recurrence, so schedules are stored as rrule strings and expanded on read rather than materialised as thousands of rows. Three scheduled jobs run behind the app: archiving what's finished, cleaning up orphaned records and files, and sending reminders before meetings and vote deadlines. They sit on public endpoints that verify their caller before doing anything.

The WhatsApp analytics started as a curiosity and became the feature leadership liked most. You export a chat, upload it, and an AI pass summarises themes, activity over time and overall sentiment — enough to notice a problem in week two instead of month three.

The problem that cost me the most hours had nothing to do with any of that. Invitation emails were being silently dropped because of how the sending domain was configured — the app reported success, the recipients got nothing. It took a while to even see, because everything in the logs looked fine. Fixing the domain setup fixed it, and I added a visible delivery state so the next failure announces itself.