ADR 0002: Spätere private Benutzerkonten und Familien-Workspaces

Status: Deferred
Datum: 2026-07-01

Kontext

Immohai ist aktuell als private Web-App mit statischem Frontend-MVP aufgebaut.

Der erste MVP konzentriert sich bewusst auf:

ein Objekt
Quick Mode
Best/Base/Stress
Jahresprojektion
Kern-KPIs
ETF-Vergleich
Ampelbewertung
Annahmenherkunft

Nicht Teil des aktuellen MVP sind:

Backend
Datenbank
Login
Benutzerverwaltung
Objektspeicherung
Objektvergleich
Sharing

Langfristig soll Immohai aber nicht nur einzelne Analysen im Browser berechnen, sondern Immobilienanalysen speichern und später vergleichbar machen können.

Ein sinnvoller zukünftiger Anwendungsfall ist privater Zugriff für Familie oder eng vertraute Personen.

Entscheidung

Immohai soll später private Benutzerkonten und optional Familien-Workspaces unterstützen können.

Diese Funktion wird ausdrücklich als spätere Ausbaustufe dokumentiert und ist nicht Teil des aktuellen MVP.

Der Charakter der App bleibt:

private App
kein SaaS-Fokus
keine öffentliche Immobilienplattform
keine fremde Mandantenverwaltung

Zielbild

Langfristig soll es möglich sein:

Benutzerkonto
  → eigene gespeicherte Immobilienanalysen
  → eigene Objektdatenbank
  → Notizen und Status je Objekt
  → Objektvergleich
  → optionaler gemeinsamer Familien-Workspace

Für Familienzugriff ist ein Workspace-Modell sinnvoller als nur einzelne isolierte Benutzerkonten.

Beispiel:

Workspace: Familie
  Mitglieder:
    - Admin
    - Editor
    - Viewer

  Gemeinsame Objektdatenbank:
    - Objekt 1
    - Objekt 2
    - Objekt 3

Rollenmodell

Ein mögliches späteres Rollenmodell:

Rolle	Rechte
Admin	Workspace verwalten, Mitglieder einladen, Objekte anlegen, bearbeiten und löschen
Editor	Objekte anlegen und bearbeiten
Viewer	Objekte und Auswertungen ansehen

Die genaue Rechtevergabe wird später entschieden.

Mögliche Datenstruktur

Eine spätere Backend- und Datenbankstruktur könnte grob enthalten:

users
workspaces
workspace_members
properties
property_inputs
property_analyses
scenario_results
assumptions
notes

Wichtig:

RawListing oder importierte Rohdaten werden nicht direkt berechnet.
Berechnet wird immer ein normalisiertes PropertyInput.

Sicherheits- und Datenschutzgrundsätze

Da Immohai finanzielle und immobilienbezogene Daten enthalten kann, gelten für diese spätere Ausbaustufe hohe Anforderungen.

Mindestgrundsätze:

• keine Secrets im Repository.
• keine echten vollständigen Objektadressen in Testdaten.
• keine persönlichen Finanzdaten in Testdaten.
• rollenbasierter Zugriff auf Workspaces.
• klare Trennung von Benutzern, Workspaces und Objekten.
• sichere Authentifizierung.
• einfache Möglichkeit, Familienmitglieder wieder zu entfernen.

Konsequenzen für die aktuelle Architektur

Aktuell wird nichts davon implementiert.

Die Entscheidung hat aber folgende Konsequenzen für spätere Modellierung:

• PropertyInput sollte langfristig speicherbar sein.
• Berechnungsergebnisse sollten als ScenarioResult oder PropertyAnalysis persistierbar sein.
• Annahmenherkunft bleibt wichtig, weil gespeicherte Analysen nachvollziehbar sein müssen.
• Objektvergleich und Datenbankanalyse sollten später auf gespeicherten PropertyRecords aufbauen.
• Frontend-MVP und spätere Backend-Engine dürfen keine divergierende Berechnungslogik entwickeln.

Nicht-Ziele

Nicht Ziel dieser Entscheidung:

• öffentlicher SaaS-Betrieb.
• kommerzielle Mandantenfähigkeit.
• öffentliche Inseratsplattform.
• Zugriff für beliebige Dritte.
• Rechts-, Steuer- oder Finanzierungsberatung.

Offene Fragen

Vor Umsetzung zu klären:

1. Welche Authentifizierung wird genutzt?
2. Wird es nur lokale/private Benutzer geben oder externe Login-Provider?
3. Wie werden Workspaces eingeladen und verwaltet?
4. Welche Daten dürfen geteilt werden?
5. Wie werden gelöschte Objekte und Analysen behandelt?
6. Welche Backup- und Exportfunktionen braucht eine private Familiennutzung?
7. Ab welchem Schritt wird eine Datenbank eingeführt?

Umsetzungshorizont

Diese Entscheidung wird erst relevant nach:

1. stabilem Frontend-MVP
2. stabiler Berechnungsspezifikation
3. definiertem Datenmodell
4. Backend-/API-Entscheidung
5. erster Objektspeicherung

Erst danach sollten Benutzerkonten und Familien-Workspaces umgesetzt werden.