Skip to content

Roadmap

tom-schorn edited this page Sep 26, 2026 · 3 revisions

Roadmap

V1 — das erste Release

V1 ist die erste Version für andere. Danach gibt es nur noch Fehlerbehebungen (1.0.x), bis V2 beginnt. Das läuft:

  • Planen — für den Folgemonat entsteht ein Plan aus den Verträgen; Abhaken eines Postens erzeugt die Buchung. Verpflichtungen mit Häkchen, Limits ohne
  • Verträge — Vertrag, Einnahme, Sparziel und Schuld, mit Abstand (alle 1 bis 120 Monate), erster Fälligkeit und Laufzeitende. Ein Sparziel mit Zielbetrag wird nicht mehr eingeplant, sobald es erreicht ist
  • 50/30/20 als Richtlinie — Grundbedarf, Wünsche, Sparen gegen die Quote, mit persönlichem Standard und einer Haushaltsquote; die drei Quoten ergeben immer 100
  • Konten und Buch — Kontostand aus Anfangsbestand plus Buchungen, Umbuchungen, durchlaufende Posten, „zählt als verfügbar“
  • Verlauf — Kurve durch den Monat für das Standardkonto: geplant, bis gebucht ist; mit Engpass-Hinweis und optionalem Monatsübertrag als Startstand
  • Hinweise im Plan — heute „überfällig“ und „Engpass“, vom Backend berechnet
  • Haushalt — gemeinsame Sicht auf die Pläne aller Mitglieder, Einladungen, Freigaben pro Bereich, Paar-Preset, Partnerplan bearbeiten
  • Import — Kontoauszüge als CSV und CAMT einlesen, Vorschläge für die Zuordnung zu Posten
  • Rückgängig statt Rückfrage und keine Zeilenmenüs — die Regeln für die Oberfläche stehen im UI-Leitfaden
  • Instanzebene — wer sich registrieren darf (REGISTRATION_MODE), ein Admin für Einladungen (ADMIN_EMAIL), Impressum, Datenschutzerklärung und AGB als Textdateien des Betreibers
  • Druckversion, Dark- und Light-Theme
  • Selbsthosten — zwei Images plus Compose-Datei, zusammen unter 256 MB
  • Pipeline — Prüfungen an jedem Pull Request, Images bei jedem Merge, Version und Changelog über release-please

Bekannte Grenzen von V1: Hinweise rechnen mit der Serverzeit (UTC im Container), nicht mit Europa/Berlin. Ein Sparziel kennt keine Entnahmen; gezählt wird, was per Abhaken gebucht wurde. Bestehende Monate ziehen neue Verträge nicht von selbst nach (#10).


V2 — Verträge, Forderungen, Gemeinschaftskonten

Der Kern von V2 ist, Verträge über den MVP hinaus zu verwalten und Geld sichtbarer zu machen, das nicht einfach fließt:

  • Verträge erweitern — Anbieter, Vertragsnummer, Kündigungsfrist (#21)
  • Forderungen — unbezahlte Rechnungen, Mahngebühren und Inkasso als eigener Bereich (#89)
  • Gemeinschaftskonten — ein Konto mit mehreren Eigentümern (#92)
  • Sparziele mit eigenem Stand — pro Ziel, auf einem Sparkonto, mit Entnahmen (#86)
  • Fairer Anteil an gemeinsamen Posten nach Einkommen (#53)
  • Überweisungen an ein Haushaltsmitglied nicht mehr doppelt zählen (#4)
  • Dashboard als Startseite (#56)
  • Offene Sitzungen anzeigen und einzeln abmelden (#37)
  • PDF-Kontoauszüge lesen (#76)
  • Kindergeld-Auszahlungstage aus der Kindergeldnummer ableiten (#20)

Bankanbindung

Kontostände und Buchungen sollen nicht mehr von Hand oder per Import hereinkommen. Zwei Wege, noch nicht entschieden (#16):

  • FinTS / HBCI — direkt an die Bank, keine ablaufende Zustimmung. Dafür nur Deutschland, und es braucht eine Produktregistrierung bei der Deutschen Kreditwirtschaft.
  • PSD2 über einen Anbieter (z. B. GoCardless) — europaweit und ohne Registrierung bei den Banken, aber die Zustimmung muss alle 90 bis 180 Tage erneuert werden, und das Onboarding dauert Wochen.

Die beiden Wege unterscheiden sich beim Depot: FinTS kann Depotbestände bei der verwahrenden Bank abfragen — bei Scalable Capital ist das die Deutsche Bank, und WISO finanzblick liest es auf diesem Weg. PSD2 kann das nicht, es deckt nur Zahlungskonten ab.

App

Eine mobile App ist gewünscht, aber kein Selbstzweck. Findet sich jemand, der App-Entwicklung übernimmt, wird sie richtig gebaut. Findet sich niemand, weichen wir auf Capacitor aus: dieselbe React-Codebasis in einer nativen Hülle, kein zweites Frontend. (#17)


V3 — Anträge

Anträge nachhalten: Leistungen, die beantragt wurden, mit ihren Fristen und Entscheidungen (#90).


Wie es entsteht

Die erste Fassung ist im Dialog mit einer KI entstanden — Vibe-Coding, Schritt für Schritt, ohne Tests und ohne festen Aufbau. Das war Absicht: es ging darum, das Problem einmal vollständig abzubilden und zu sehen, ob das Konzept trägt. Es trägt.

Seitdem wird mit KI-Unterstützung weitergearbeitet, aber mit festem Rahmen: jede Arbeit hat ein Issue, jedes Stück wird unabhängig geprüft, und Tests laufen in der Pipeline bei jedem Pull Request. Duofy versteckt das nicht — die Kontextdatei CLAUDE.md im Repository macht es nachvollziehbar.

Clone this wiki locally