Membership, dues and minutes for lodges that still run on paper
Lodge administration runs on spreadsheets, filing cabinets and one secretary who remembers everything. Acacia Leaf puts membership, dues, meetings and documents in one system - with every record held in Canada.
Visit acacialeaf.net- Canada
- Data residency
- Postgres in Canada Central
- Row-level
- Tenancy
- Per-lodge isolation in the database
- CSV import
- Onboarding
- Auto-mapped and previewed first
- Cycle to receipt
- Dues
- Charges reconciled via Stripe
The challenge
A lodge secretary is a volunteer. The roster lives in a spreadsheet, dues are reconciled against a cheque book, attendance is a paper sheet in a binder, and the history of who was initiated when sits in minute books nobody can search.
When the secretary changes, much of that knowledge leaves with them.
The blocker on adopting anything off the shelf was jurisdictional rather than technical. These are personal records of identifiable people, held by an organisation in British Columbia, and the membership is not comfortable with them sitting in a US database. Any credible answer had to keep the data in Canada and be able to say so precisely.
What we did
We started with one lodge and one slice - get the roster in - because a membership system nobody has loaded their members into is worth nothing. The importer takes whatever spreadsheet already exists, maps the columns itself, splits full names, normalises degree and standing values, and shows a preview before a single row is written.
From there the model grew to cover what a secretary actually does across a year: dues cycles that generate per-member charges, payments reconciled against them through Stripe, meetings with attendance and visiting brethren recorded, a document library, and notices out to the membership.
Data residency is a design constraint rather than a footnote. Postgres runs in Supabase Canada Central, row-level security scopes every query to a lodge so one lodge can never read another, and the server holds the only key that can read member data.
The outcome
The system is built and deployed, and spans what a secretary does across a year: membership, dues and payments, meetings and attendance, documents, milestones and communications. Multi-lodge tenancy sits underneath it, so adding a lodge is an invitation rather than a deployment.
The roster importer was deliberately the first thing built rather than the last, because adoption dies at the point where somebody has to retype four hundred members.
The data-residency position is the part expected to make the case: member records sit in Canada, and that can be stated plainly rather than hedged.