Your pages, your policies, your platform
The public site, the legal documents and the shape of the deployment itself, all editable without a release. Including the one people forget: bumping a privacy policy has to ask members to accept it again.
Pages you can edit
About, contact, privacy, terms and refunds are rich-text documents your team edits directly. Content is sanitised on the way in with a closed allow-list, because a CMS editor is another route by which markup reaches a page that renders it.
Versioned policies and re-consent
Privacy and terms carry version numbers. Publish a new version and members are asked to accept it at their next login, with what they agreed to and when kept on the record. This is the difference between having a privacy policy and being able to show that a member accepted the current one.
Module flags per organisation
Switch off what you do not run. A disabled module disappears — no menu item, no greyed-out screen, no prompt to upgrade. Combined with permissions, this is what makes one deployment fit an organisation with three committees and another with thirty.
Your identity, everywhere
Name, logo, colours, domain and contact details, applied across the public site, the member portal and the admin panel. Members should see your organisation, not the software.
Settings & CMS — questions
If yours is not here, ask on a call. We answer specifics.
Can we change modules after launch?
Yes, at any time. Turning one off hides it and leaves the data intact, so it can be turned back on.
Who can edit the legal pages?
Only roles holding that grant. In most organisations that is one or two people, and every change is in the audit log.
Can we use our own domain?
Yes — all three surfaces run on your domain. That is what single-tenant means in practice.
See settings & cms against your own setup
Bring the awkward case — the exception your constitution requires, the thing your current system cannot do. That is the useful half of a demo.