Custom Terminology

Each of the four founding organizations uses different terminology for the same concepts - a mismatch between app language and the organization's own vocabulary creates cognitive friction and reduces trust in the platform. When coordinators see "Kontakt" but their organization always calls them "Bruker", every screen feels subtly wrong. Custom terminology eliminates this friction without requiring per-organization code branches, which would be unsustainable at scale. The label override system also reduces training overhead: staff and volunteers recognize familiar terms immediately rather than having to learn platform-specific language. As Meander onboards more organizations, this feature becomes a key differentiator that makes the platform feel purpose-built for each tenant, increasing retention and reducing churn.

Label overrides are stored in the organization_labels PostgreSQL table as key-value pairs scoped to an organization ID. The API exposes the full label map for the authenticated user's organization as part of the session bootstrap payload, so no extra round-trip is needed at startup. The Flutter app stores labels in a Drift table and resolves them through a centralized LabelService that all widgets query - no hardcoded strings in UI code. The admin portal terminology editor provides a form listing all overrideable keys with their current values and platform defaults, with inline validation ensuring values are non-empty strings within length limits. Adding a new overrideable key requires only adding it to the label key registry and providing a platform default - no schema migration needed. The mobile organization labels system currently supports contact, my_contacts, peer_mentors and is designed to be extended to singular forms and role terms without structural changes.