Zum Inhalt springen
aviral gupta

// LEISTUNG 07 — NEXT.JS-BUILDS

Ein Next.js-Entwickler, der die schnelle Version zuerst ausliefert.

Produktive Next.js-Architekturen, gebaut mit den Mitteln des Frameworks selbst. Fein gezogene Grenzen zwischen Server- und Client-Komponenten, Rendering-Strategie je Route über SSR, SSG und ISR, und Core-Web-Vitals-Budgets, die direkt in der CI/CD-Pipeline durchgesetzt werden.

✓ 326 SEO-Seiten für Cariva ausgeliefert · ✓ Migration von Laravel zu Next.js ohne Ranking-Verluste · ✓ sechs Node.js-Microservices im produktiven Einsatz

Architekturfokus
Rendering- und Caching-Strategie pro Route, Hydration-Kosten im Budget gehalten
System-Benchmark
Ein produktives Next.js-Codebase, das Ihnen gehört
Verifikationsstufen
Lighthouse-CI-Prüfungen, Bundle-Budget-Checks, Playwright-Interaktionsregression

Alle Leistungen

// TECHNISCHE VERANTWORTUNG

Was bekomme ich, wenn ich einen Next.js-Entwickler beauftrage?

App-Router-Architektur

Route Groups, verschachtelte Layouts, parallele und abfangende Routen dort, wo sie ihren Platz verdienen, und eine loading.tsx-Boundary-Strategie, damit die Navigation nie auf die langsamste Query wartet.

Server Components als Standard

React Server Components übernehmen das Datenladen; Client Components sind die Ausnahme und auf das kleinste interaktive Blatt begrenzt, damit das ausgelieferte JavaScript proportional zu dem bleibt, was Nutzer tatsächlich anfassen.

Rendering pro Route gewählt

Statische Generierung für Marketing-Seiten, ISR mit On-Demand-Revalidierung für Katalog-Inhalte, gestreamtes SSR für alles Personalisierte. Ein einziger Rendering-Modus für eine ganze Website ist eine Entscheidung, die niemand bewusst getroffen hat.

Performance-Budgets in der CI

LCP-, INP- und CLS-Zielwerte stehen vor der ersten Komponente fest und werden bei jedem Pull Request mit Lighthouse CI geprüft — eine Regression lässt den Build scheitern, statt drei Monate später aufzufallen.

Durchgängig typisiert

TypeScript im Strict Mode mit typisierten Route Handlers, Zod-validierten Formular- und API-Grenzen und generierten Typen für Ihre Datenquelle — falsche Strukturen scheitern zur Compile-Zeit statt erst in der Produktion.

SEO fest im Build verankert

Metadata API pro Route, Canonicals und hreflang, generierte Sitemaps und Robots-Regeln sowie JSON-LD, das zu dem passt, was jede Seite tatsächlich ist — während des Builds geschrieben, nicht nach dem Launch angeflanscht.

Ein UI-System statt einzelner Screens

Design Tokens, barrierefreie Komponenten auf nativer Semantik, Dark Mode und Reduced-Motion-Handling sowie ein Layoutsystem, das CLS bei null hält, weil Platz reserviert wird, bevor Inhalte eintreffen.

Deployen, überwachen, dokumentieren

CI/CD zu Vercel oder in Ihre eigene Infrastruktur, Umgebungs- und Secret-Handling, Fehler- und Web-Vitals-Monitoring sowie schriftliche Runbooks, damit das Team die Codebasis ohne mich betreiben und erweitern kann.

// ABLAUF

Wie funktioniert es?

  1. 1

    Erstgespräch

    Eine Session darüber, was Sie bauen, für wen es gedacht ist und welche Seiten oder Workflows zählen. Ich gehe mit genug Material heraus, um den Aufwand ehrlich einzuschätzen.

  2. 2

    Architektur und Budgets

    Route-Map, Rendering-Strategie pro Seite, Datenquellen und das Core-Web-Vitals-Budget, das der Build halten muss. Schriftlich festgehalten und freigegeben, bevor der erste Code committet wird.

  3. 3

    In sichtbaren Etappen bauen

    Funktionierende Seiten auf einer Preview-URL ab der ersten Woche, ausgeliefert in Etappen, die Sie anklicken können. Sie prüfen echte Screens statt Mockups, solange Änderungen noch günstig sind.

  4. 4

    Härten und verifizieren

    Lighthouse- und Felddaten-Checks, Accessibility-Durchlauf, Validierung von Metadaten und Schema, Analytics-QA und Lasttests auf den Routen, die Geld tragen.

  5. 5

    Launch und Übergabe

    Deployment, 30 Tage Monitoring, danach Übergabe von Repository, Dokumentation und einem Walkthrough, damit Ihr Team von dort übernehmen kann.

// NACHWEIS

Wo habe ich das produktiv betrieben?

Cariva ist das klarste Beispiel. Ich habe eine Autoverkaufs- und Gebrauchtwagenplattform in Next.js gebaut, die auf 326 SEO-Seiten gewachsen ist — aus strukturierten Daten generiert, nicht von Hand gebaut. Das Rendering wurde pro Template gewählt, statisch für Marketing-Routen, inkrementelle Regenerierung für den Katalog, sodass die Seitenzahl skalierte, ohne dass Build-Zeit oder Crawl-Budget mitskalierten. Dieselben architektonischen Gewohnheiten flossen in Thrifty und Dollar Autovermietung in den VAE ein, wo Thriftys PHP-Laravel-Monolith ohne Ranking-Verluste auf Next.js migrierte und Dollars .NET-Backend durch sechs gemeinsam genutzte Node.js-Microservices ersetzt wurde.

326 SEO-Seiten bei CarivaLaravel → Next.js, keine Ranking-Verluste6 produktive MicroservicesSEO 100 · CLS 0,00 auf dieser Website

Die vollständige Fallstudie lesen

// TOOL-STACK

Welche Tools nutze ich?

Next.js 16React 19TypeScriptTailwind CSSTurbopackNode.jsMongoDBVercelnext-intlZodLighthouse CIGitHub Actions

Dieselben Tools, mit denen ich auch Ihre Website prüfe.

// FAQ

Was sollten Sie über meine Arbeitsweise dabei wissen?

Zwei bis sechs Wochen für die meisten Next.js-Builds, je nach Seitenzahl und Zahl der dahinterliegenden Integrationen. Eine fokussierte Marketing-Website mit einer Handvoll Templates liegt am unteren Ende dieser Spanne, eine Katalog-Website mit CMS, Payments und Suche am oberen. Das Umfangsdokument legt die Spanne fest, bevor wir beginnen, und die Preview-URL ist in Woche eins live — Sie sehen den Fortschritt, statt auf ihn zu warten.

Ihnen, vollständig, ab dem ersten Commit. Ich arbeite in Ihrem Repository oder übergebe am Ende eines mit vollständiger Commit-Historie; der Vertrag überträgt Ihnen mit der Schlusszahlung sämtliche Rechte am geistigen Eigentum. Es gibt keine lizenzierten Komponenten, für die Sie mich dauerhaft bezahlen müssten, kein proprietäres Framework und keine Bindung an mich persönlich. Wenn Sie mich nächsten Monat ersetzen, kann ein anderer Senior-Entwickler das Projekt anhand der README übernehmen.

Ja, und ich unterschreibe Ihre, statt auf meiner zu bestehen. Schicken Sie sie vor dem Audit-Gespräch, wenn auch dieses erste Gespräch abgedeckt sein soll. Ich verwende Kundencode nie in anderen Projekten wieder, Zugangsdaten bleiben in Ihrem Passwortmanager statt auf meinem Rechner, und nichts erscheint ohne schriftliche Erlaubnis in meinem Portfolio oder auf dieser Website. Wo keine Erlaubnis vorliegt, beschreibe ich die Arbeit über die Architektur statt über den Kundennamen.

Ich verkaufe kein Hosting weiter, und Sie sollten Entwicklern misstrauen, die das tun. Next.js läuft am besten auf Vercel — vom selben Team gebaut, mit ISR, Bildoptimierung und Edge-Caching ohne Konfigurationsaufwand. Wenn Sie auf AWS, Azure oder Ihrer eigenen Infrastruktur bleiben müssen, deploye ich dorthin und sage Ihnen, welche Funktionen Sie dabei verlieren. Der Account läuft auf Ihren Namen, und Sie zahlen direkt beim Anbieter.

Ja, und oft ist das die bessere Konstellation. Ich habe den Großteil der letzten neun Jahre in Engineering-Teams verbracht — Mercedes-Benz R&D, Grid Dynamics und jetzt Thrifty Car Rental UAE —, deshalb sind Code Review, Branch-Disziplin und Sprint-Rituale für mich normal und keine Zumutung. Ich kann das Next.js-Frontend verantworten, während Ihr Team die API behält, mit einem Junior pairen, der das Codebase übernimmt, oder einen klar abgegrenzten Teil bauen und ansonsten nicht im Weg stehen.

// OFFEN FÜR NEUE ROLLEN

Sagen Sie mir, was Sie bauen — ich schneide den Next.js-Build darauf zu.