Wie ich eine mehrsprachige Next.js-Website in 3 Tagen erstellt habe

Eine mobile App ohne Website ist wie ein Restaurant ohne Schild. Du kannst die beste Küche der Welt haben, niemand wird dich finden. Als mir klar wurde, dass TAMSIV eine Schaufenster-Website brauchte – Landing Page, Preise, FAQ, rechtliche Seiten – setzte ich mir ein ehrgeiziges Ziel: 3 Tage, keinen mehr.

72 Stunden später war tamsiv.com online. Mehrsprachig (6 Sprachen), responsiv, mit einem animierten Hero, SEO-optimierten Seiten und einem Lighthouse-Score von 94/100/100. Hier ist der vollständige Bericht dieses Sprints, die technischen Entscheidungen, die Fallstricke und was ich anders machen würde.

Wichtige Erkenntnisse:
- Next.js 16 mit App Router ist ideal für eine performante, mehrsprachige Schaufenster-Website
- Die Internationalisierung mit next-intl sollte von Anfang an konfiguriert werden, nicht nachträglich hinzugefügt
- Führe immer npm run build lokal aus, bevor du auf Vercel deployst
- Responsives Design erfordert mehr Iterationen als erwartet – plane 30% der Gesamtzeit ein
- Ein Lighthouse-Score von 90+ ist in 3 Tagen mit den richtigen Architektur-Entscheidungen erreichbar

Warum Next.js statt Gatsby, Astro oder einfachem HTML?

Die Wahl des Frameworks ist nicht unerheblich. Ich habe mehrere Optionen in Betracht gezogen:

• Statisches HTML/CSS: Am einfachsten, aber unhandlich für 6 Sprachen und über 20 Seiten. Jede Änderung müsste 6 Mal repliziert werden.
• Gatsby: Gut für statische Websites, aber die Build-Zeit und das alternde Plugin-Ökosystem haben mich abgeschreckt.
• Astro: Exzellent für statische Inhalte, aber ich wusste, dass ich später interaktive Komponenten (Auth, Dashboard) benötigen würde.
• Next.js 16: App Router, React Server Components, hybrides Rendering (statisch + dynamisch), native i18n. Und vor allem kenne ich React – es ist dasselbe Ökosystem wie das mobile TAMSIV Frontend.

Die Wahl von Next.js ergab sich auch aus einem praktischen Grund: Ich wusste, dass sich die Website über eine einfache Schaufenster-Website hinaus entwickeln würde. Das QR-Code-Authentifizierungssystem, das App-Dashboard, das Admin-Panel – all das erfordert ein Framework, das dynamische, geschützte Seiten verwalten kann.

Wie organisiert man einen 3-Tages-Sprint effizient?

Drei Tage sind kurz. Ohne Planung verbringst du den ersten Tag mit der Einrichtung deiner Umgebung und kommst am dritten Tag ohne Inhalt an. So habe ich den Sprint aufgeteilt:

Tag 1: Technische Grundlagen (10 Stunden)

Der erste Tag ist vollständig der technischen Infrastruktur gewidmet. Nichts Sichtbares für den Benutzer, aber alles andere hängt davon ab:

• Setup Next.js 16 mit TypeScript, App Router, Tailwind CSS 4
• Internationalisierung mit next-intl – 6 Sprachen (FR, EN, DE, ES, IT, PT) von Anfang an konfiguriert
• Lokalisiertes Routing: /fr/fonctionnalites, /en/features, /de/funktionen... jede Seite hat eine übersetzte URL
• Basis-Layout: Header, Footer, responsive Navigation, dunkles Thema (#101922)
• Vercel-Konfiguration: Git-Repo verbunden, automatische Preview-Deployments

Das lokalisierte Routing hat mich allein 2 Stunden Konfiguration gekostet. Mit next-intl muss jede Route mit ihren Slug-Übersetzungen deklariert werden. Das ist ausführlich, führt aber zu sauberen und SEO-freundlichen URLs in jeder Sprache.

Tag 2: Inhalt und Design (12 Stunden)

Der intensivste Tag. Hier nimmt die Website Gestalt an:

• Animierter Hero: Partikelhintergrund auf dunklem Hintergrund #101922, mit einem primären CTA. Ich habe eine 3D-Spline-Szene für das Hauptvisual verwendet.
• Inhaltsseiten: Anwendungsfälle (4 Szenarien), Funktionen (responsives Raster), Preise (3 Pläne mit Funktionsvergleich), FAQ (Akkordeon)
• Copywriting: Jede Seite zuerst auf Französisch, dann übersetzt. Der Ton: direkt, duzend, auf Benutzervorteile ausgerichtet
• Responsives Design: Hier habe ich die meiste Zeit verbracht. Die Funktionsraster (3 Spalten → 2 → 1) erforderten 3 Iterationen. Der animierte Hero auf Mobilgeräten erforderte einen statischen Fallback für die Performance.

Tag 3: SEO, Performance und Deployment (8 Stunden)

Der letzte Tag ist all dem gewidmet, was die Website "professionell" macht:

• Technische SEO: generateMetadata() pro Seite mit Open Graph, Sprachalternativen, dynamische XML-Sitemap
• Analytics: GA4 mit RGPD Consent Mode (kein Tracking ohne Zustimmung)
• Rechtliche Seiten: Impressum, Datenschutzerklärung, AGB, Cookies
• Performance: Bildoptimierung, Lazy Loading, Preloading kritischer Schriftarten
• Vercel Deployment: Und dann... der Kampf.

Warum ist das erste Vercel-Deployment fehlgeschlagen?

Der Moment der Wahrheit. git push, der Vercel-Build startet... und schlägt fehl. TypeScript-Fehler. Dann noch einer. Dann ein dritter.

Was passiert ist: In der lokalen Entwicklung ist Next.js tolerant gegenüber bestimmten Typfehlern. Der Produktions-Build (next build) ist streng. Implizite any-Typen, fehlende Imports, nicht behandelte optionale Props – all das geht in der Entwicklung durch und bricht in der Produktion.

Die Lektion, die ich auf die harte Tour gelernt habe: Führe immer npm run build lokal aus, bevor du pushst. Das dauert 30 Sekunden und erspart 3 Stunden Debugging in den Vercel-Logs (die weniger lesbar sind als die lokale Ausgabe).

Die häufigsten Fehler, die ich behoben habe:

• Implizite Typen: function Component({ data }) → function Component({ data }: { data: DataType })
• Unbenutzte Imports: Der Build behandelt sie als Fehler, nicht als Warnungen
• Umgebungsvariablen: Präfix NEXT_PUBLIC_ ist obligatorisch für clientseitig zugängliche Variablen
• Alternates Metadata: Die URLs jeder Sprache müssen absolut sein, nicht relativ

Wie konfiguriert man die Internationalisierung mit next-intl von Anfang an?

Die i18n war das Thema, das mich am ersten Tag am meisten Zeit gekostet hat. Mit next-intl erfordert das initiale Setup Sorgfalt:

1. Nachrichtendateien: Eine JSON-Datei pro Sprache (messages/fr.json, messages/en.json...). Identische Struktur, identische Schlüssel, übersetzte Werte.
2. Middleware: Automatische Erkennung der Browsersprache, Weiterleitung zum richtigen Präfix (/fr/, /en/).
3. Routing: Jede Seite befindet sich in einem [locale]-Ordner. Die Slugs werden über eine Mapping-Datei übersetzt.
4. Komponenten: useTranslations('section'), um auf die Übersetzungen in jeder Komponente zuzugreifen.

Die klassische Falle: Ohne i18n beginnen und es später hinzufügen. Ich habe Projekte gesehen, bei denen das Wochen des Refactorings gekostet hat. Indem ich es am ersten Tag eingerichtet habe, ist jede Komponente bereits für 6 Sprachen bereit. Die automatische Übersetzung über LLM kümmert sich dann darum.

Ein wichtiger Punkt: Der HTML-Inhalt des Blogs wird in separaten Dateien (content/blog/{locale}/{slug}.html) gespeichert, nicht in den JSON-Dateien. Warum? Weil next-intl HTML-Tags als ICU-Variablen interpretiert und Fehler generiert. Diese Trennung hat mir Stunden des Debuggings erspart.

Wie erreicht man einen Lighthouse-Score von 90+ mit Next.js?

Der finale Lighthouse-Score: 94 Performance, 100 Barrierefreiheit, 100 SEO. Hier sind die wichtigsten Optimierungen:

• Optimierte Bilder: <Image>-Komponente von Next.js mit sizes und priority für LCP. Automatisches WebP-Format.
• Kritische Schriftarten: next/font für Google Fonts mit display: swap. Keine Layout-Verschiebung.
• Lazy Loading: Alle Below-the-Fold-Komponenten werden bei Bedarf geladen. Der animierte Hero ist der einzige, der sofort geladen wird.
• Atomares CSS: Tailwind CSS 4 generiert minimales CSS – nur die verwendeten Klassen sind enthalten.
• Statische Generierung: Alle Inhaltsseiten werden beim Build vorgerendert. Kein Server zur Laufzeit für statische Inhalte.

Der kritischste Performance-Punkt war der animierte Hero. Die Partikelanimation auf dunklem Hintergrund war schön, aber schwer. Ich musste einen Schwellenwert implementieren: Auf Mobilgeräten wird die Animation durch einen statischen Gradienten ersetzt. Auf Desktops startet sie erst nach dem LCP (Largest Contentful Paint).

Welche Seiten sind für eine mobile App-Schaufenster-Website unerlässlich?

Für einen Start brauchst du keine 50 Seiten. Hier ist das Minimum Viable, das ich in 3 Tagen erstellt habe:

1. Landing Page: Hero + Anwendungsfälle + Funktionen + Preise + FAQ + CTA. Das sind 80% des Traffics.
2. Über uns: Wer steckt hinter dem Projekt. Für einen Solo-Entwickler ist das ein Glaubwürdigkeitsvorteil.
3. Datenschutzerklärung: Obligatorisch für den Play Store und die RGPD.
4. Nutzungsbedingungen: Obligatorisch für In-App-Abonnements.
5. Cookie-Richtlinie: Obligatorisch mit dem RGPD-Cookie-Zustimmung.
6. Blog: Optional beim Start, aber ich habe die Struktur bereits am 3. Tag eingerichtet. Der Blog ist zu einem wichtigen SEO-Akquisitionskanal geworden.

Jede Seite existiert dank i18n in 6 Sprachen. Das sind über 30 Seiten, die aus 6 Vorlagen generiert wurden. Das Verhältnis von Aufwand zu Wirkung der i18n ist enorm – ich spreche ausführlich darüber in meinem Artikel über i18n als Akquisitionskanal.

Wie hat sich die Website nach dem initialen Sprint entwickelt?

Die 3 Tage legten die Grundlagen. Seitdem hat sich die Website erheblich weiterentwickelt:

• Dashboard-App (/app/tasks, /app/memos, /app/agenda): Vollständige Weboberfläche zur Verwaltung von Aufgaben und Memos über einen Browser. Authentifizierung per QR-Code oder E-Mail.
• Admin-Panel (/admin/dashboard): Benutzerstatistiken, Recharts-Diagramme, Warnungen. Detailliert im Artikel über das Admin-Dashboard.
• SEO-Blog: Über 40 technische Artikel, optimiert für Suchmaschinen, mit KI-generierten Bildern.
• Öffentliche Roadmap: Roadmap-Seite mit gelieferten und kommenden Funktionen.
• Benutzerhandbuch: Interaktive Dokumentation für neue Benutzer.

All dies wäre ohne die soliden Grundlagen der ersten 3 Tage nicht möglich gewesen. Der App Router von Next.js, die native i18n, das automatische Vercel-Deployment – jeder Baustein, der am Anfang gelegt wurde, hat spätere Ergänzungen erleichtert.

Welche Ratschläge für einen Solo-Entwickler, der seine Website im Sprint startet?

Wenn du ein Solo-Entwickler bist und schnell eine Schaufenster-Website starten möchtest, hier sind meine 5 Empfehlungen:

1. Wähle ein Framework, das du kennst: Dies ist nicht der Zeitpunkt zum Lernen. Verwende, was du beherrschst.
2. Konfiguriere die i18n am ersten Tag: Auch wenn du nur in einer Sprache übersetzt, ist die Struktur vorhanden. Das Hinzufügen von Übersetzungen später wird trivial sein.
3. Build lokal vor jedem Push: npm run build. Systematisch. Ohne Ausnahme.
4. Mobile First für CSS: Beginne mit dem Mobilgerät, füge die Desktop-Breakpoints hinzu. Das Gegenteil kostet immer mehr Zeit.
5. Ship early, iterate later: Eine unvollkommene Website online ist besser als eine perfekte Website, die nur auf localhost existiert. Die Korrekturen werden kommen.

FAQ

Wie viel kostet das Hosting einer Next.js-Website auf Vercel?

Der kostenlose Plan von Vercel reicht für die meisten Schaufenster-Websites aus. Er beinhaltet SSL, globales CDN und Preview-Deployments. Ich nutze immer noch den kostenlosen Plan für tamsiv.com, auch mit über 40 Seiten und regelmäßigem Traffic.

Sollte man Tailwind CSS oder ein anderes CSS-Framework verwenden?

Tailwind CSS ist ideal für einen schnellen Sprint. Du codierst das Design direkt im JSX, keine separaten CSS-Dateien erforderlich. Der Nachteil: Der HTML-Code ist ausführlich. Aber für einen Solo-Entwickler, der schnell sein möchte, wird der Overhead der Lesbarkeit durch die Entwicklungsgeschwindigkeit weitgehend kompensiert.

Wie verwaltet man Übersetzungen ohne professionellen Übersetzer?

Ich verwende ein Skript zur automatischen Übersetzung über OpenRouter (LLM). Das Skript erkennt geänderte Schlüssel (delta-only), übersetzt nur das, was sich geändert hat, und kostet etwa 0,05 EUR pro Durchlauf. Die Qualität ist für technische Texte sehr gut. Details dazu findest du im Artikel über die i18n in 6 Sprachen.

Ist SEO mit generateMetadata von Next.js ausreichend?

generateMetadata() verwaltet Titel, Beschreibung, Open Graph und Alternates (hreflang). Das ist ausreichend für 90% der On-Page-SEO-Anforderungen. Ich habe eine dynamische Sitemap und eine robots.txt für das Crawling hinzugefügt. Der Rest (Backlinks, Inhalt, Autorität) hängt vom Blog und Marketing ab.

Kann man den gleichen Sprint mit Astro statt Next.js machen?

Ja, Astro wäre für eine rein statische Website sogar schneller. Aber wenn du später dynamische Seiten (Auth, Dashboard) hinzufügen möchtest, bleibt Next.js die beste Wahl. Der Übergang von statisch zu dynamisch ist mit dem App Router transparent.