Von Idee zu Rewrite: Learnings aus meiner eigenen Buchhaltungsapp

Einleitung

Der Grundgedanke hinter meiner Buchhaltungsapp war simpel: Ich wollte nicht für ein anderes Produkt bezahlen, obwohl ich wusste, dass ich mir selbst eine Lösung bauen kann, die genau auf meine Bedürfnisse zugeschnitten ist. Dieser Gedanke ist meiner Meinung nach einer der stärksten Antriebe für ein eigenes Projekt – man hat eine echte, intrinsische Motivation. Gerade dann ist das hilfreich, wenn es keine externen Motivatoren wie Deadlines, Kund:innen oder ein Team gibt. Eine der größten Herausforderungen bei der Umsetzung als Solo-Projekt war für mich allerdings, strukturiert vorzugehen.

Backend

Als ich mit der Entwicklung der App begann, war Backend-Entwicklung für mich noch völlig neu. Ich hatte zwar eine grobe Vorstellung davon, welche Bestandteile ein Backend umfasst, doch zum Beispiel über die Validierung von Requests habe ich mir erst sehr spät Gedanken gemacht. Solche Versäumnisse können mit der Zeit dazu führen, dass Bugs entstehen und das Backend instabil wird.

Auch die Auswahl der Technologien basierte größtenteils nicht auf meinen eigenen Erfahrungen, sondern wurde stark durch Tutorials und externe Empfehlungen geprägt.

Datenbank

Als ich mit der App anfing, schien MongoDB die perfekte Wahl zu sein: flexibel, einfach zu starten und in Tutorials weit verbreitet. Damals habe ich sogar direkt mit dem Frontend begonnen, ohne mir früh Gedanken über das Datenbankdesign zu machen. Rückblickend würde ich heute damit starten, weil das Design der Datenbank dabei hilft, Anforderungen klar zu definieren und Beziehungen zwischen Entitäten zu verstehen.

Mittlerweile würde ich für dieses Projekt eher eine relationale Datenbank wählen. Sie erlaubt es, Daten konsistent zu strukturieren, Beziehungen zwischen Entitäten klar abzubilden und komplexe Abfragen umzusetzen. Dazu gehören beispielsweise Aggregationen wie das Berechnen des Jahresumsatzes aus allen Rechnungen oder Reports, die offene Rechnungen nach Kunden gruppieren. Solche Aufgaben lassen sich mit relationalen Datenbanken oft einfacher und effizienter umsetzen als mit einer rein dokumentenbasierten Lösung.

Framework

Bei der Wahl des Frameworks fiel meine Entscheidung auf Express.js. Das Framework ist minimalistisch und bringt keine fertigen Lösungen wie Authentifizierung, Validierung oder vorgefertigte Strukturen mit. Diese Kontrolle war ideal, um viel über die einzelnen Bausteine eines Backends zu lernen.

Heute würde ich diese Entscheidung hinterfragen. Je nach Projektgröße und Anforderungen könnten Frameworks mit mehr „Batteries“ praktisch sein, um Zeit zu sparen und etablierte Patterns zu nutzen, ohne alles selbst bauen zu müssen.

Neben der Wahl des Frameworks habe ich im Backend weitere wichtige Learnings gesammelt:

• Validierung sollte früh eingeplant werden, sonst schleichen sich Bugs und Inkonsistenzen ein.
• Logging ist essentiell für Debugging und Monitoring, wird aber oft unterschätzt.
• Authentication und Sicherheit müssen von Anfang an mitgedacht werden.
• Standard Responses und Types helfen, das Backend konsistent zu halten, insbesondere wenn Types zwischen Datenbank und Code synchronisiert werden.

Frontend

Beim aktuellen Rewrite habe ich zusätzlich auf das nuxt/ui-Modul gesetzt und direkt mit dem Dashboard Starter Kit begonnen. Das hat den Vorteil, dass man sofort ein solides Design hat und viele kleine Probleme, die sonst Zeit kosten würden, bereits gelöst sind. Man kann sich also voll auf die Logik und die Features der App konzentrieren, statt sich um die Details der Oberfläche zu kümmern.

Ein Punkt, den ich damals im ersten Projekt vernachlässigt habe, war die Abstraktion der API-Requests. Jeder neue Endpoint, der angebunden werden musste, erzeugte relativ viel Boilerplate-Code. Die Nuxt-Server-Schicht hätte eigentlich nur als Proxy dienen sollen, sodass diese Schicht nie erweitert werden muss. Heute würde ich von Anfang an eine saubere Abstraktion aufsetzen, um wiederverwendbaren und wartbaren Code zu haben.

Arbeitsprozess & Architektur im Rewrite

Beim Rewrite habe ich den Arbeitsprozess komplett umgestellt. Viel Zeit habe ich zunächst in das Design des Datenbankschemas investiert. Erst als dieses feststand, konnte ich mit der Symfony CLI die Models generieren. Dadurch standen sofort alle CRUD-Endpunkte zur Verfügung – das Backend war so zu einem großen Teil quasi „automatisch“ fertig.

Auch das Architekturbewusstsein hat sich deutlich verändert. So habe ich beispielsweise die PDF-Generierung in einen eigenen Hono-Service ausgelagert. Dadurch wird der Backend-Request nicht blockiert, und Symfony bleibt ausschließlich für die API zuständig. Gleichzeitig konnte ich so weiterhin meinen favorisierten Ansatz für die PDF-Erstellung mit Playwright verwenden, da Playwright nur in JavaScript funktioniert.

Ein weiterer Unterschied zum ersten Projekt war die strukturierte Ticket-Erstellung: Dank KI-Unterstützung konnte ich detaillierte Tickets schreiben, die klar und sauber abgearbeitet wurden. Das hat den gesamten Entwicklungsprozess deutlich effizienter und nachvollziehbarer gemacht.

Dieses Projekt hat mir mehr Lektionen beigebracht als jedes andere zuvor. Ich bin froh, dass ich mich daran gewagt habe, und dankbar für jeden Fehler, aus dem ich lernen konnte. Es wird mich noch eine Weile begleiten, und ich bin gespannt, welche neuen Erkenntnisse noch auf mich warten.