Next.js ist mein Standard für Webprodukte – nicht, weil es gerade angesagt ist. Eine einzige TypeScript-Codebasis deckt damit ab, wofür früher drei Projekte nötig waren: die Marketingseite, die in Suchmaschinen gefunden werden soll, die Anwendung hinter dem Login und die schlanke API-Schicht dazwischen. Diese Website ist ein kleines Beispiel: lokalisierte Routen, generierte Metadaten, Sitemap, Open-Graph-Bilder und eine llms.txt-Route – alles in einem App-Router-Projekt.
Ich beginne mit dem Server. Seiten und Layouts sind standardmäßig Server Components: Sie rufen Daten nahe an der Datenbank ab, senden HTML statt eines JavaScript-Bundles und halten Geheimnisse auf dem Server. „use client“ setze ich nur an den Blättern des Komponentenbaums ein, die Zustand, Effekte oder Browser-APIs benötigen – etwa bei einem Formular, Dropdown oder einer Karte. Beginnt der Baum ganz oben mit „use client“, folgen meist ein großes Bundle und eine ganze Klasse von Fehlern.
Die Wahl des Rendering-Modus ist eine Produktentscheidung, keine technische. Statische Generierung eignet sich für Seiten, die sich nur mit einem Deployment ändern. ISR oder tagbasierte Revalidierung passen zu Katalogen, Angeboten und Blogs, die sich im Tagesverlauf ändern: revalidateTag nach einem Schreibvorgang statt eines Timers, den niemand versteht. Dynamisches Rendering mit Suspense-Streaming nutze ich für Dashboards und personalisierte Inhalte: Das Gerüst erscheint sofort, langsamere Daten folgen nach und nach. Für jede Route halte ich fest, warum sie statisch oder dynamisch ist. Diese eine Zeile erspart später eine Woche mit der Frage: „Warum ist der Preis veraltet?“
Für Änderungen nutze ich Server Actions bei Formularen, die zur Seite gehören, und Route Handlers, wenn ein externer Dienst die Anwendung aufrufen muss – etwa ein Zahlungsanbieter oder Telegram per Webhook, ein mobiler Client oder ein Cron-Job. In beiden Fällen validiert Zod die Eingaben auf dem Server, die Authentifizierung wird dort geprüft, und der Client entscheidet nie über Geld oder Berechtigungen. Bei größeren Produkten bleibt Next.js Frontend und BFF; die zentrale Domänenlogik liegt in einem NestJS- oder Node.js-Dienst mit eigener Datenbank.
Performance und SEO gehören für mich zur Definition of Done. Dazu zählen next/image mit passenden Größen, next/font gegen Layout-Verschiebungen, generateMetadata und strukturierte Daten auf jeder öffentlichen Seite, dynamische Importe für große Widgets und Core Web Vitals, die ich auf einem Mittelklasse-Smartphone statt einem MacBook prüfe. Deployen kann ich auf Vercel, wenn das Team keinen Betriebsaufwand will, oder als Standalone-Build im Docker-Container auf AWS oder einem VPS, wenn Kosten, Datenstandort oder lange laufende Aufgaben wichtig sind.
Was ich ablehne: „use client“ im Root-Layout, dieselben Daten ohne Cache-Konzept in fünf Komponenten abzurufen, Geschäftslogik in Middleware zu verstecken und an einem Freitag ohne Prüfung der Codemods auf eine neue Hauptversion zu wechseln. Wenn sich deine Next.js-Anwendung langsam oder fragil anfühlt, schick mir das Repository und die zwei langsamsten Seiten. Ich sage dir, was ich auf den Server verschieben, cachen und entfernen würde.
Geben Sie dem nächsten Produkt jemanden, der bleibt.
Bereit für den Start? Schreiben Sie mir – ich kann sofort beginnen und bleiben. Langfristige Mandate statt Übergabe nach zwei Wochen. Lassen Sie uns über Ihr Projekt, die Anforderungen und den besten Weg nach vorn sprechen.