Die Frage «Welches Framework nehmen wir?» kommt in fast jedem Projekt als erstes. Sie ist gut gemeint. Sie ist selten die richtige erste Frage.
Frameworks sind Meinungen über Probleme, die jemand anderes hatte. Manchmal sind diese Meinungen deckungsgleich mit dem, was du brauchst. Oft genug sind sie es nicht. Und du merkst es erst, wenn das System steht.
Was stattdessen: Wir fangen mit den Anforderungen an. Wirkliche Anforderungen, nicht «wir brauchen eine Web-App». Was muss das System können? Wie viele Nutzer, welche Lastmuster, welche Integrationen, welche Lebensdauer? Erst wenn das klar ist, wird über Technologie entschieden.
Meistens ist die Antwort dann weniger überraschend als man denkt. Gute, bewährte Tools für die jeweilige Aufgabe. Aber die Begründung ist eine andere. Nicht «alle machen es so», sondern «es passt auf diese spezifischen Anforderungen».
Das hat einen praktischen Effekt: Wenn sich Anforderungen ändern. Und sie ändern sich immer. Ist die Architekturentscheidung nachvollziehbar und anpassbar. Nicht verheiratet mit einem Stack, der vor zwei Jahren modern war.
Bei AI-Produkten ist das noch wichtiger. Die Modell-Landschaft verändert sich schnell. Wer seine KI-Logik an ein spezifisches Modell oder eine spezifische Plattform koppelt, baut tech debt von Tag 1. Wer Abstraktionsschichten baut, bleibt beweglich.
Framework-first ist bequem. Problem-first ist besser.
