Antworten zu Frontend-Frameworks, Backend-Sprachen, Schnittstellen, Onboarding und externer Verstärkung.
Frontend und Backend in einer Hand. Im Frontend bevorzugt Angular, daneben React, Next.js oder Vue je nach Projekt. Im Backend nehme ich, was bei euch schon läuft, mit sicherem Umgang aus 20 Jahren Praxis in Java, C#, PHP und Node.js. Schnittstellen zwischen den Schichten ziehe ich sauber als Verträge, statt sie händisch wachsen zu lassen.
Es hängt von drei Fragen ab: was läuft bei euch schon, wie groß wird die Anwendung und wer pflegt sie in fünf Jahren. Angular ist für komplexe Enterprise-Anwendungen die ruhigere Wahl, Next.js für inhaltlich geprägte Sites mit Server-Side-Rendering, Vue für überschaubare Tools. Ein neues Framework einzuführen, weil es modern wirkt, ist selten wirtschaftlich.
Java mit Spring Boot, C# mit .NET, PHP mit Symfony oder Laravel und Node.js mit NestJS oder Express. In allen vieren habe ich produktive Erfahrung aus mehreren Projekten. Welche Sprache am Ende zum Einsatz kommt, gibt euer Bestand vor, nicht meine Vorliebe. Ich passe mich an euren Stack an.
Ein JSON-Schema ist eine maschinenlesbare Definition, wie eine API-Antwort aussehen muss. Frontend und Backend generieren ihre Modelle daraus. Wenn sich auf einer Seite etwas ändert und mit dem Schema bricht, fällt das beim Build auf, nicht beim Kunden. Klassen von Bugs an der Frontend-Backend-Naht verschwinden vollständig.
Beides hat Berechtigung. REST bleibt der ruhigere Weg bei klar abgegrenzten Ressourcen, mit flacher Lernkurve, einfachem Caching und vorhersehbaren URLs. GraphQL spielt seine Stärken aus, wenn Frontends unterschiedliche Sichten auf dieselben Daten brauchen. In vielen Mittelstands-Projekten reicht REST. GraphQL einzuführen, weil es modern wirkt, kostet mehr Tooling-Aufwand als es Mehrwert bringt.
Ein Monorepo hält Frontend und Backend im selben Repository. Sinnvoll, wenn Änderungen regelmäßig beide Seiten betreffen, ein Schema geteilt wird und das Team in das nötige Tooling investiert. Bei getrennten Teams, die unabhängig releasen, oder wenn kein geteilter Code da ist, bringt ein Monorepo nur Komplexität ohne echten Vorteil.
Im Bestand, Stück für Stück. Das alte System bleibt produktiv, einzelne Komponenten werden nacheinander durch neue ersetzt. Der Reflex zum großen Schnitt mit Parallel-Bau scheitert in der Realität meistens, weil sich Anforderungen weiter ändern. Schrittweise ist langsamer in der Wahrnehmung, aber deutlich schneller im Ankommen.
Hängt an zwei Fragen: wie lange braucht ihr die Kapazität wirklich, und wie spezifisch ist die Aufgabe für eure Domäne. Bei stabilen, fachlich tiefen Aufgaben ist intern fast immer richtig. Bei zeitlich begrenzten oder spezialisierten Aufgaben ist extern pragmatischer. Ein erfahrener Externer ist oft nicht teurer, wenn ihr alle Kosten ehrlich rechnet.
Repo klonen, ein Befehl, lokale Umgebung läuft. Seed-Daten, die typische Fälle abbilden. Geheimnisse, die nicht im Repo liegen, aber dokumentiert sind. Tests, die out-of-the-box durchlaufen. Und eine Person, die in den ersten zwei Wochen fragbar ist. Wer dieses Setup pflegt, holt jedem neuen Entwickler Wochen Onboarding-Zeit zurück.
Schrittweise, eine Major-Version nach der anderen. Pro Schritt: Breaking Changes aus dem offiziellen Update-Guide adressieren, Tests anpassen, Dependencies aktualisieren. Wer drei oder vier Versionen auf einmal überspringen will, stößt auf inkonsistente Fehler, die kaum zu debuggen sind. Bei Bestand-Anwendungen plane ich vier bis acht Wochen für drei Major-Versionen, abhängig von Größe und Test-Abdeckung.
Tagessätze für erfahrene selbständige Entwickler liegen in einer Bandbreite, die stark von Spezialisierung, Engagement-Modell und Projektkontext abhängt. Bei längerfristiger Begleitung sind Tagessätze niedriger als bei kurzfristigem Eingriff. Ein konkretes Angebot bekommt ihr nach dem Erstgespräch, sobald Aufgabe, Umfang und gewünschte Zusammenarbeit geklärt sind.
Ja. Ich arbeite seit Jahren in Scrum- und Kanban-Setups, oft in bestehenden Teams. Wenn euer Team Tickets, Reviews und Daily-Strukturen hat, integriere ich mich da, statt eigene Prozesse aufzudrücken. Die ersten Pull Requests entstehen typischerweise in der ersten Woche.
