MVP 49 features

Core org metadata, support access grants, and settings schema; foundation for custom terminology, feature toggles, and hierarchy management.

User invite, deactivation, and admin user repository are prerequisites before roles can be assigned or any user can log in.

Auth foundation for the entire platform. Email/password MVP scope; BankID/Vipps deferred to v1.0. Enables all role-gated screens.

Statutory accessibility statement screen; static content embedded in app with no runtime dependencies.

Drift + SQLCipher encrypted local DB, mutation outbox, and conflict resolver are the mobile data layer foundation; must exist before any feature writes local state.

In-app static legal screen; no technical dependencies, authored in parallel with all development work.

Design token system (colors, spacing, typography) and semantic label helpers must be established before any screens are built; WCAG 2.2 AA is a hard MVP requirement with no opt-out.

Static cookie policy and consent banner on the sales site; independent of operational products.

GDPR-required DPA; static content with no backend dependency.

Static feature showcase on the sales site; fully independent from operational products.

Static legal page on the sales site; no technical dependencies.

Static marketing page on the sales website; zero backend dependency, can be authored and deployed from day one.

Static legal page; independent of all operational code.

Audit entries reference user and org context established by auth; trail must be active from first login including Global Admin support-access sessions.

Terminology editor and labels service extend org settings; per-org label overrides must be scoped to an existing org record.

Module toggle service and repository are the runtime switch for optional areas; the toggle page is the admin surface that must exist before any optional module can be enabled per tenant.

Links users to organizations and handles NHF's multi-membership (up to 5 local associations) cases; requires both user management and org management.

Hierarchy management supports NHF's 12 national associations / 1,400 local chapters structure; depends on the org settings schema for parent/child relationships.

Role assignment widget and admin role service depend on the user management foundation; enables org-scoped admin portal features.

Admin session overview and forced revocation depend on the token issuance mechanism from email-password-login.

RoleGuard widget and RBAC service gate all role-sensitive screens; must follow auth establishment and precede every feature screen.

Sync queue, retry/backoff scheduler, and outbox processor are built on top of the offline data layer; required before any feature syncs data to the server.

Demo booking form POSTs to a lightweight email/webhook endpoint; independent of the operational backend.

Purely client-side static calculation on the sales website; no backend or auth dependency, placed in tier 2 to let tier 1 content pages ship first.

Admin activity feed shows recent actions scoped to the org; needs role-based scoping from the role assignment layer.

Approval workflow in the admin portal gates activity data quality; role assignment determines which users can approve which activities.

Admin KPI cards aggregate org-scoped user and activity data; requires role assignment to be in place for meaningful org-scoped metrics.

Aggregates session and audit metrics; both data sources must exist before the dashboard can display meaningful security KPIs.

Multi-step wizard (contact → date → duration → summary) is the full-form activity entry path; runs in parallel with quick-log since both share the same activity service.

App-level settings screen persists preferences per user; requires auth context but has no complex data dependencies.

Caregiver section extends the contact model with next-of-kin relationships; depends on the base contact infrastructure established by contact-list-search.

Contact detail and edit screens depend on the contact data model and role-based read/write permissions.

Contact list and search require role-gated access and offline persistence; both foundational layers must be ready.

Support request form pre-populates user identity from auth context; no complex data dependencies.

Event creation wizard mirrors the activity wizard structure; can be built in parallel by a separate feature team.

Event list screen is a read-only view on the same events data layer as event-creation; simpler surface that ships together.

Notification preference storage and settings screen are straightforward once the push infrastructure is available.

Profile screen and edit form store per-user settings; role context determines which fields are visible per role.

Firebase Messaging client and push service require role context for routing and sync infrastructure for reliable delivery.

Case link widget associates a relative record to a contact case; depends on the relative contact data model.

Relative registration extends the contact model for Barnekreftforeningen's family-centric workflow; foundational for case linking and role tagging.

Role tagging (parent, sibling, guardian) enriches relative records; can be built alongside case linking since both extend the same relative entity.

Home dashboard assembles role-appropriate widgets at runtime from the module registry; Peer Mentor and Coordinator variants share the same assembly mechanism.

Screen reader warning widget overlays sensitive data fields; requires the WCAG design token system and role context to determine which fields require warnings.

Quick-log screen is the platform's highest-priority feature; requires RBAC for role-specific flows and offline support for field workers.

Confirmation page shown after successful demo booking; requires the booking form webhook to be wired up first.

Admin team report page aggregates approved activity data at the organization level; depends on the approval workflow producing validated records.

Coordinator team report aggregates across all managed peer mentors; requires activity data and role scoping to produce meaningful output.

Personal stats screen aggregates activity data per peer mentor; depends on at least one activity registration path being complete and producing data.