Content for teams that want to implement with more clarity.

No borders: any rite, any language, any lodge

Freemasonry is universal, yet most lodge management systems were built for a single country, a single language and a single rite. A lodge with brethren of different nationalities, an obedience with lodges abroad or a ritual with its own offices is enough for such a system to stop working.

In Fraterly, each member uses the platform in their own language, even when the lodge brings together people who speak different languages. Grand lodges, obediences and supreme bodies with lodges and chapters in several countries each run in their own language, currency and jurisdiction, on the same platform.

There are no fixed offices either. The lodge uses the structure of its rite or creates its own, as with a new ritual whose offices differ from all others. Men's, women's and mixed lodges are handled the same way.

Meeting attendance and voting happen in the app, checked by geolocation, so that every record is auditable and valid.

For Fraterly none of this is an exception or a custom build: it is simply how the system works.

How to take minutes, correspondence and secretary work out of operational chaos

Many lodges still rely on scattered messages, documents on personal computers and versions with no control. The result is predictable: lost minutes, confusing reviews, missing attachments and secretary work that depends too heavily on the individual currently in office.

When the routine is structured as a flow, secretary work stops being merely personal effort and becomes institutional capacity. Session, agenda, minutes, review, approval, signature and archive stop being isolated pieces and become one coherent process.

That is why Fraterly treats minutes and correspondence as a dedicated module: with context, responsible officers, session documents, history and traceability. The value is not “digitisation for its own sake”; it is preventing the lodge’s administrative memory from becoming fragmented again.

Digital attendance with traceability without trivialising the meeting

Attendance is not just a button. In many lodges, it affects regularity, internal statistics, excuses and administrative follow-up for the brother. If digital attendance is treated as a contextless click, it loses seriousness.

That is why attendance needs rules: correct session, correct context, time window, absence justification, supporting document when necessary and, in some scenarios, geolocation validation. The goal is not excessive surveillance, but record integrity.

The proper design also clearly separates what the brother does from what the secretary sees afterwards. The brother confirms, justifies and attaches. The secretary receives clear fields, history, decision and audit trail. That separation reduces confusion and operational error.

Proper onboarding is not registration: it is operational start-up

A common SaaS mistake is to treat onboarding as mere data collection. In the Fraterly context, that would be insufficient. The entity must move from contracting to operation with named officers, validated minimum data, initial configuration and, when possible, member import already reconciled.

That is why the design includes contracting, email confirmation, initial access, onboarding, entity data, temple, rooms, import, review and initial role definition. It reduces the gap between “bought the product” and “can already work”.

Good onboarding is not what asks for less information. It is what asks for the right information, in the right order, with enough validation to allow a real operational start.

Documents by degree: when the library stops being just a folder

A masonic library cannot be treated as a single directory with generic permissions. There are public, private and restricted documents and, above all, materials whose access depends on degree, context and administrative role.

When classification is weak, organisation becomes vulnerable. When classification is strong, the lodge gains documentary governance: it knows who can see a document, who changed it, which version is valid and what the full history is.

In Fraterly, the library, ritual documents, works and papers were conceived as a structure with document type, degree-based access, history and traceability. That is very different from simply “storing PDFs”.

What an obedience really needs to see across its lodges

An obedience does not need to invade lodge autonomy to have a consolidated view. It does need enough visibility and indicators to support, guide and decide responsibly. How many active brothers are there? Which lodges have pending items? Which documents are missing? What is the distribution by degree?

Without this, the obedience manages in the dark. With this, it can act with institutional maturity. Fraterly tries to balance precisely those two things: local autonomy and consolidated visibility.

That balance is only possible when context, role, permissions and reporting are designed from the foundation — not bolted on afterwards.

Dues, receipts and collection: why lodge finance needs rhythm

Many lodges handle finance through manual effort and informal memory: spreadsheets, messages, scattered reminders and receipts issued without coherent history. The problem is that treasury does not need only records; it needs rhythm.

Rhythm means knowing what is due, what is overdue, who has been reminded, which receipt was issued, which agreement exists and what each brother’s individual status is. For the brother the experience should be simple. For treasury it must be operational and clear.

That is why, in Fraterly, brother finance and lodge finance cannot look like the same screen. The system needs to distinguish personal view from administrative view.

Sentinel doesn't solve problems. It stops them from happening.

Most management problems in a Lodge don't appear out of nowhere. They build up in silence. Minutes left unapproved. A brother who missed three sessions and nobody spoke to him. An insurance policy expiring in two months that nobody checked. A role left vacant when the term ended and no election process was started.

Sentinel was designed exactly for these situations. It's not a checklist someone has to run manually. It's an always-on service that monitors, classifies and communicates — to the right person, at the right time, with enough context to act.

What makes Sentinel different isn't just what it monitors natively. It's the fact that the Lodge can create its own alerts. The Secretary defines specific rules for that Lodge, for that rite. Sentinel learns from the structure it serves. The more the system is fed, the more precise and useful it becomes.

It's the icing on the cake. A product that operates can be good. A product that anticipates is rare.

◆ Learn more about Sentinel →

A Masonic vote is not just any vote

There's a fundamental difference between a generic vote and a vote within a Masonic Lodge or Grand Lodge. It's not just technical. It's cultural, ritual and institutional. Summoning has rules. Eligibility depends on degree. The secret ballot is a value, not an option. The minutes are a formal document, not an informal summary.

That's why adapting a generic voting tool to Masonic reality always results in gaps. Missing traceability of participation without breaching secrecy. Missing a snapshot of the electoral college at the exact moment of opening. Missing real-time quorum validation. Missing integration with members' profiles and degrees.

Assembly was designed from scratch for this context. The flow covers formal summoning, eligibility definition, controlled opening, voting with MFA when applicable, automatic tallying and minutes generation — with a complete history of every vote held by the Lodge, accessible, auditable, preserving secrecy where applicable.

The outcome of a Masonic vote needs to be beyond dispute. Not just the result itself, but the process that produced it.

◆ Learn more about Assembly →