Dies ist Teil 4 unserer Redesign-Serie. Teil 1: Warum · Teil 2: Strategie · Teil 3: Design

---

Der Elefant im Raum: WordPress

Lass uns ehrlich sein: WordPress ist großartig. Für Millionen von Websites. Für unsere nicht mehr.

Unser altes Setup war ein klassisches WordPress-Theme mit einem Dutzend Plugins. Es hat funktioniert – irgendwie. Aber mit jedem Update wurde es fragiler. Ein Plugin-Konflikt hier, ein Sicherheitspatch dort, und plötzlich verbringst du mehr Zeit mit der Website-Pflege als mit dem eigentlichen Business.

Das eigentliche Problem war aber ein anderes: WordPress hat uns limitiert, nicht enablet. Wir wollten Animationen, die sich natürlich anfühlen. Layouts, die kein Page-Builder kann. Interaktionen, die über "Klick hier, Accordion öffnet sich" hinausgehen. Und vor allem: Geschwindigkeit.

Die Entscheidung für den neuen Stack

React + Vite: Schnell, modern, flexibel

Die Wahl fiel auf React als UI-Framework und Vite als Build-Tool. Warum?

• Komponentenbasiert – jede Section, jedes Element ist wiederverwendbar und isoliert testbar
• Vite ist unfassbar schnell – Hot Module Replacement in Millisekunden, nicht Sekunden
• TypeScript – Typsicherheit verhindert eine ganze Klasse von Bugs, bevor sie passieren
• Ecosystem – Framer Motion für Animationen, TanStack Query für Daten, Tailwind für Styling

Für eine Beratungswebsite klingt React vielleicht wie Overkill. Ist es nicht. Denn unsere Website ist gleichzeitig unser Showroom. Wenn wir Kunden empfehlen, modern zu bauen, sollten wir das selbst auch tun.

Tailwind CSS: Utility-First, Design-System-Ready

In Teil 3 haben wir über unser Design-System gesprochen. Tailwind CSS ist der Grund, warum es funktioniert:

• Semantic Tokens statt Magic Numbers – bg-primary statt bg-[#0d9488]
• Dark Mode mit einem Klick – CSS Custom Properties machen's möglich
• Konsistenz erzwungen – das Spacing-System lässt keine willkürlichen Abstände zu
• Kein CSS-Bloat – nur die Klassen, die wir tatsächlich nutzen, landen im Bundle

Lovable: AI-First Development

Hier wird es spannend. Wir haben den Großteil dieser Website mit Lovable gebaut – einem AI-First Development Tool, das React-Anwendungen generiert und iteriert.

Warum Lovable statt klassischer Entwicklung?

• Geschwindigkeit – eine vollständige Landingpage in Minuten statt Tagen
• Iteration – "Mach den Hero größer, ändere die Animation" als Prompt statt als Ticket
• Konsistenz – das AI versteht das Design-System und wendet es automatisch an
• Proof of Concept – wir beraten zu AI-Tools, also nutzen wir sie selbst

Das heißt nicht, dass Lovable alles allein gemacht hat. Es gab Stellen, an denen wir manuell nachjustiert haben – komplexe Animationen, SEO-Feinheiten, die Content-Architektur. Aber der Grundsatz war: AI für die 80%, Handarbeit für die 20%.

Markdown statt CMS: Content als Code

Die kontroverseste Entscheidung – und die, die sich am meisten gelohnt hat.

Wie es funktioniert

Jeder Blogpost ist eine .md-Datei im Repository:

src/content/blog/
├── redesign-warum-vision-marke-alignment.md
├── redesign-strategie-positionierung.md
├── redesign-design-system.md
└── redesign-techstack-lovable-vite.md   ← dieser Artikel

Jede Datei hat einen Frontmatter-Block mit Metadaten (Titel, Datum, Autor, Kategorien) und darunter den eigentlichen Inhalt in Markdown. Beim Build parst Vite die Dateien, rendert das Markdown zu HTML und macht alles als statischen Content verfügbar.

Warum das besser ist als ein CMS

Aspekt	WordPress/CMS	Markdown im Repo
Geschwindigkeit	API-Call pro Seitenaufruf	Alles beim Build kompiliert
Versionierung	Plugin oder manuell	Git – jede Änderung nachvollziehbar
Deployment	FTP oder Plugin-Deploy	Push → Auto-Deploy
Sicherheit	Plugin-Updates, Patches	Keine Angriffsfläche
Abhängigkeit	Hosting, Datenbank, PHP	Nur das Repository
Backup	Extra-Plugin nötig	Git IS the backup

Der eigene Frontmatter-Parser

Statt eine schwere YAML-Library einzubinden, haben wir einen minimalen Frontmatter-Parser geschrieben. Er versteht Skalare, Listen, verschachtelte Objekte – alles, was wir für Blog-Metadaten brauchen, in unter 130 Zeilen Code.

// Minimal, aber ausreichend
const frontmatter = parseFrontmatter(rawMarkdown);
// → { title, slug, date, author: { name, slug }, categories, tags, ... }

Events als Content-Typ

Ein besonderes Feature: Events sind keine separate Entität, sondern Blogposts mit zusätzlichen Frontmatter-Feldern. Ein Post mit categories: [Events] und event_date wird automatisch auf der Events-Seite angezeigt – mit Unterscheidung in "Kommend" und "Vergangen".

Ein Content-Typ, ein System, null Redundanz.

Deployment: Von Push zu Live

Das Deployment ist erfrischend langweilig – und das ist gut so:

1. Code pushen → Git Repository
2. Build triggern → Vite kompiliert alles zu statischem HTML/JS/CSS
3. Deploy → Vercel serviert die Dateien von der Edge
4. Fertig → Weltweit verfügbar in unter 30 Sekunden

Kein FTP, kein Datenbank-Backup, kein "Hat jemand das Plugin aktualisiert?". Einfach Push und vergessen.

Performance: Die Zahlen sprechen

Der Wechsel von WordPress zu unserem neuen Stack hat die Performance dramatisch verbessert:

• First Contentful Paint: Von ~2.5s auf unter 1s
• Bundle Size: Unter 300KB für die gesamte Anwendung
• Lighthouse Score: Konstant über 90 in allen Kategorien
• Time to Interactive: Unter 1.5s auf Mobile

Das ist kein Zufall, sondern Architektur: Kein unnötiger JavaScript-Ballast, kein Plugin-Overhead, keine Datenbankabfragen.

Die Kompromisse

Ehrlichkeit gehört dazu. Es gibt Dinge, die mit WordPress einfacher wären:

• Nicht-technische Redakteure können nicht einfach im Browser schreiben – Markdown und Git sind Voraussetzung
• Kein WYSIWYG-Editor – Vorschau nur über den Dev-Server oder nach dem Deploy
• SEO-Plugins wie Yoast fehlen – SEO muss manuell implementiert werden
• Kommentare und Formulare brauchen externe Services

Für uns als technisches Team sind das keine Nachteile. Für ein Marketing-Team mit zehn Redakteuren wäre dieser Stack die falsche Wahl. Context matters.

Das Learning: Eat your own Dog Food

Der wichtigste Takeaway aus Teil 4: Nutze die Tools, die du empfiehlst. Wir beraten zu AI-First, also bauen wir AI-First. Wir empfehlen moderne Stacks, also nutzen wir moderne Stacks. Wir predigen Pragmatismus, also wählen wir den Stack, der für uns pragmatisch ist – nicht den, der theoretisch am meisten kann.

Das Ergebnis: Eine Website, die schnell ist, die wir komplett kontrollieren, und die gleichzeitig zeigt, was mit den richtigen Tools möglich ist.

---

Nächster Artikel: Redesign Teil 5 – Go-Live: Die neue Website und unsere Ausrichtung für 2026

Vorheriger Artikel: Teil 3 – Design: Von der Farbpalette zum Design-System