Das Problem mit Musikfirmen-Websites
Eine Firma wie feldhaus macht mehrere Dinge gleichzeitig. Es gibt ein Tonstudio mit drei Räumen, das man buchen kann. Es gibt ein Label mit Künstler:innen und Releases. Es gibt die edition feldhaus, einen Musikverlag. Und es gibt Booking für Live-Auftritte.
Der übliche Weg wäre eine Navigationsleiste mit vier Punkten und vier Unterseiten, die nichts miteinander zu tun haben. Das funktioniert, aber es erklärt nicht, warum diese vier Dinge zusammengehören. Es sieht aus wie vier Firmen unter einem Dach.
Die Idee: eine Oberfläche, die alle kennen
Wer Musik hört, bedient jeden Tag dieselbe Art von Interface. Seitenleiste links, Kachelreihen in der Mitte, unten eine Player-Leiste, die beim Scrollen stehen bleibt. Diese Anordnung muss niemandem erklärt werden — sie ist gelernt.
Also haben wir die Seite genau so gebaut. Releases sind Alben, Künstler:innen sind Profile, das Studio ist ein weiterer Bereich in derselben Seitenleiste. Wer die Startseite öffnet, versteht in zwei Sekunden, wie er sich bewegt — und nebenbei, dass all das zu einer Firma gehört.
Was das konkret heißt
- Seitenleiste
- Alle Bereiche gleichzeitig sichtbar — Releases, Roster, Studio, Label, Edition, Booking. Kein Menü, das man erst öffnen muss.
- Kachelreihen
- Releases und Künstler:innen als horizontale Reihen, wie eine Mediathek. Das Cover trägt, nicht die Überschrift.
- Player-Leiste
- Bleibt beim Navigieren bestehen. Man kann eine Hörprobe starten und weiterklicken, ohne dass die Musik abbricht.
- Sofortsuche
- Tippen filtert den Katalog direkt — Künstler:innen, Releases und einzelne Titel in einer Liste.
Der Studiobereich bricht bewusst aus dem Muster aus. Räume, Technik und Preise brauchen Fließtext und Fotos, keine Kacheln. Die Seitenleiste bleibt, der Inhalt wird zur Reportage. Eine Metapher trägt nur so weit, wie sie dem Inhalt hilft — darüber hinaus wird sie zum Korsett.
Die Technik
- Next.js 16, React 19, TypeScript
- App Router, alles als statischer Export. Es läuft nirgends ein Node-Prozess.
- Tailwind CSS v4 und shadcn/ui
- shadcn auf Base UI als Komponentenschicht — Dialoge, Schieberegler, Formularelemente barrierefrei ohne Eigenbau.
- Eigener Wiedergabe-Zustand
- Der Player ist keine fertige Bibliothek, sondern React-State über dem Layout. Nur so überlebt die Wiedergabe einen Seitenwechsel.
- Cloudflare Pages
- Der Build legt fertiges HTML in out/ ab. Für den Formularversand läuft daneben eine Pages Function, die die Eingaben prüft und an Postmark weitergibt.
- Platzhalter aus dem Skript
- Ein Python-Skript erzeugt Cover, Porträts und Klangbeispiele, solange die echten Dateien fehlen. Die Seite ist dadurch von Tag eins vollständig bedienbar.
Gebaut mit Claude Code
Das Projekt ist von Anfang bis Ende mit Claude Code entstanden — nicht als Codegenerator für einzelne Schnipsel, sondern als Mitarbeiter am gesamten Projekt: Struktur, Komponenten, Datenmodell, Deployment, Dokumentation.
Der Gewinn liegt weniger im Tippen als im Durchhalten. Ein Player-Zustand, der über Seitenwechsel trägt, ein Katalog, dessen Tracklisten serverseitig aus den Sekundenangaben rendern, ein Deployment mit Formular-Endpunkt und Header-Regeln — das sind Details, die in einem Projekt dieser Größe sonst liegen bleiben. Kein Tech-Gelaber, keine Hype-Versprechen: es ist schlicht der Unterschied zwischen sechs Wochen und sechs Tagen.
Was noch offen ist
Die Seite steht, aber sie mischt derzeit echte und erfundene Inhalte. Studio, Edition und Firmendaten stimmen; Roster, Releases, Cover und Hörproben sind Platzhalter. Sie ist deshalb für Suchmaschinen gesperrt — über noindex im Layout und einen X-Robots-Tag für Cover und Audiodateien, die kein Meta-Tag tragen können.
Das ist der ehrlichere Weg als eine halbfertige Seite mit Platzhaltern im Index. Freigegeben wird, wenn klar getrennt ist, was bleibt.