Feature Toggles
Feature Detail
Description
Feature Toggles is the admin surface for enabling and disabling functional area modules per organization. Each area in the platform taxonomy corresponds to a toggleable module; admins configure which capabilities are active for their tenant. The system enforces declared module dependencies so that enabling one area implicitly enables its prerequisites, and the UI makes this dependency graph visible to admins rather than failing silently at runtime.
Sources & reasoning
Feature Toggles is the cornerstone of the multi-tenant architecture described at length in the source. The source explicitly places the toggle UI inside Organization Management and marks admin-organization as always-on precisely because it hosts this screen. Without this feature the platform cannot serve tenants with divergent needs from a single codebase. MVP classification is confirmed by the always-on module list.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Feature Toggles is the mechanism that makes a single shared codebase viable for four organizations with materially different needs. Without it, every tenant variation requires a separate build or code branch, multiplying maintenance cost and deployment complexity. The toggles let each organization start with a minimal surface and expand capabilities as their teams mature - directly supporting the "inkrementell utrulling" principle shared by all four organizations. This also makes new tenant onboarding a configuration task rather than an engineering task, which is critical to the platform's commercial scalability. The Organization Management area must be always-on to avoid a circular dependency where the toggle UI itself gets disabled.
Module configurations are persisted in the module_configurations table (one organization to many module entries). The bootstrap API response includes the full enabled-module set; both the Flutter app and the Next.js admin portal assemble their navigation from this set at runtime. The admin UI renders a dependency graph so admins understand what enabling a module implies. Always-on modules (authentication-access-control, home-navigation, admin-dashboard, admin-organization) are displayed as non-toggleable with an explanatory tooltip. Backend endpoints for toggled modules validate the tenant's enabled set on every request to prevent API-level bypass of a disabled module by a malicious client.
Components (47)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.