Feature Toggles

The four founding organizations have materially divergent needs - encrypted assignments are critical for Blindeforbundet but irrelevant for others; course administration matters for HLF but not NHF. Without module toggles, every organization would either get features they do not need (adding clutter and confusion) or require separate code branches (unsustainable and expensive to maintain). Feature toggles allow Norse Digital Products to maintain a single codebase while serving organizations with different feature sets, dramatically reducing maintenance cost and enabling new tenant onboarding purely through configuration rather than code. The backend enforcement layer is essential for compliance and data isolation - a disabled module's API endpoints must reject requests regardless of client state, ensuring organizational boundaries are respected even if a client is modified or the toggle UI is bypassed.

Module configurations are stored in the module_configurations PostgreSQL table, scoped by organization ID and area ID. The session bootstrap API endpoint aggregates the enabled module set for the authenticated user's organization and includes it in the response payload. Both the Flutter module registry and the Next.js navigation assembly read this payload and mount only the areas that are enabled - no compile-time switching per organization. The admin portal toggle page lists all togglable areas with their current state and declared dependencies; enabling an area that requires another area implicitly enables the dependency and surfaces this to the admin. API middleware checks the enabled set on every request to a module-scoped endpoint, returning 403 if the module is disabled for the requesting user's organization. A hardcoded always-on set (authentication-access-control, home-navigation, accessibility, help-support, profile-management) is excluded from the toggle surface entirely. Changes to the enabled set are audit-logged and take effect on the next client session bootstrap.