Das hier ist kein Ranking und keine Empfehlungsliste. Es ist der Ablauf, in dem bei mir aus einer Idee eine fertige Kundenwebsite wird — vier Stationen, jede mit genau einer Aufgabe. Dazu ein Bonus, den die meisten überspringen, und das Regelwerk, das alles zusammenhält.
Der wichtigste Satz steht am Ende. Wenn du nur eine Sache mitnimmst, nimm die.
01 — INSPIRATION
Bevor irgendwas gebaut wird, muss klar sein, wie die Seite sich anfühlen soll. Für Layouts und Stimmungen: Pinterest. Für Animationen: Awwwards.
| Werkzeug | Wofür | Link |
|---|---|---|
| Stimmung, Farbwelten, Layout-Ideen — der breite Überblick | https://pinterest.com | |
| Awwwards | Preisgekrönte Seiten. Das Beste, was im Web gebaut wird | https://awwwards.com |
| 21st.dev | Fertige Komponenten-Bausteine (Hero, Cards, Navigation) | https://21st.dev |
Der eigentliche Trick: Sammel keine fertigen Designs — sammel Mechaniken.
Ein fertiges Design kannst du nicht übernehmen, ohne zu kopieren. Eine Mechanik schon: „Die Überschrift steht fest, während das Bild darunter durchscrollt.” „Die Navigation färbt sich um, sobald sie einen dunklen Bereich erreicht.” Das sind Prinzipien. Die funktionieren auf jedem Projekt, in jeder Branche, mit jeder Farbe.
Mach das so: Leg dir einen Ordner an. Bei jeder Seite, die dich umhaut, machst du einen Screenshot und schreibst in einem Satz dazu, was genau dich umgehauen hat. Der Satz ist das Wertvolle, nicht das Bild.
02 — ENTWURF
| Werkzeug | Wofür | Link |
|---|---|---|
| Claude Design | Layout als klickbaren Entwurf bauen, bevor Code entsteht | https://claude.ai |
Hier liegen die Layouts nebeneinander auf einer Fläche: Variante A, Variante B, Variante C. Du klickst dich durch, entscheidest dich für eine — und erst dann wird Code geschrieben.
Warum diese Station die wichtigste ist: Ein Layout im Entwurf umzubauen kostet Minuten. Dasselbe Layout umzubauen, wenn es schon als Code steht, kostet Tage. Die meisten Leute überspringen diesen Schritt und bezahlen ihn später doppelt.
03 — BAUEN
| Werkzeug | Wofür | Link |
|---|---|---|
| Claude Code | Der Ort, an dem gebaut wird — im Terminal | https://claude.com/claude-code |
| Astro | Das Framework. Liefert statisches HTML — die Seite ist da, bevor irgendein Skript geladen hat | https://astro.build |
| Tailwind CSS | Styling direkt im Markup, ohne separates Stylesheet-Chaos | https://tailwindcss.com |
| GSAP | Alles, was sich bewegt: Scroll-Animationen, Timelines, Sequenzen | https://gsap.com |
Warum Astro und nicht ein klassisches JavaScript-Framework: Aus Astro fällt fertiges HTML raus. Der Besucher lädt keine App, die sich erst zusammenbaut — er lädt eine Seite. Das ist der Grund, warum die Seiten schnell sind, und ganz nebenbei der Grund, warum Google sie sauber liest.
Warum GSAP und nicht die eingebauten Animationen: Sobald mehr als eine Sache passieren soll — erst erscheint das Bild, dann fährt die Schrift ein, dann startet der Scroll-Effekt — brauchst du eine Timeline. Genau das ist GSAP. Und es läuft überall, egal welches Framework darunter liegt.
04 — LIVE
| Werkzeug | Wofür | Link |
|---|---|---|
| Vercel | Hosting + Deploy. Einmal pushen, Seite ist online | https://vercel.com |
| GitHub | Der Code liegt hier — Vercel baut bei jedem Push automatisch | https://github.com |
| Porkbun | Domains (und Domain-Mail) | https://porkbun.com |
Der Ablauf: Code zu GitHub pushen → Vercel baut automatisch → Seite ist erreichbar. Danach zeigt die Domain darauf, fertig. Diese Dreifaltigkeit — Claude Code, GitHub, Vercel — ist der Grund, warum zwischen „fertig gebaut“ und „live“ bei mir Minuten liegen, nicht Tage.
Achte auf eine Sache: Wenn deine Domain woanders liegt als deine E-Mail, müssen die Mail-Einträge (MX) von Hand nachgetragen werden. Sonst steht die Seite, und keine einzige Mail kommt an. Das ist der Fehler, den fast jeder einmal macht.
Bonus — PRÜFEN, bevor der Kunde es sieht
| Werkzeug | Wofür |
|---|---|
| SEO-Audit | Technik, Ladezeit, Struktur, ob Suchmaschinen und KI-Suchen die Seite lesen können |
| Eigene Checkliste | Die Punkte, die ein Audit nicht prüft — Texte, Kontaktwege, rechtliche Seiten |
| Handy-Check | Die Seite echt am Handy durchscrollen. Nicht das verkleinerte Browserfenster — das echte Gerät |
Warum diese Station existiert: Eine Seite, die auf dem großen Bildschirm gut aussieht, kann am Handy komplett auseinanderfallen — und da schauen die meisten drauf. Diese Runde macht den Unterschied zwischen „fertig” und „abgabefertig”.
Und für Content? Dieselbe Logik.
| Werkzeug | Wofür |
|---|---|
| Claude Code | Videoideen und Skripte |
| Palmier Pro | Videos schneiden |
| HyperFrames | Videos animieren (Motion Graphics aus Code) |
Auch hier: jede Station eine Aufgabe, saubere Übergabe. Das Video, unter dem du das hier angefordert hast, ist genau so entstanden.
Das Wichtigste ist keins dieser Tools
So wie im Video gesagt: Das Wichtigste ist nicht das Tool, sondern wie du es einsetzt.
In jedem meiner Projektordner liegt eine Datei namens CLAUDE.md. Darin steht, was das Projekt
ist, welcher Stack verbindlich ist, welche Farben und Schriften gelten und welche Regeln nicht
verhandelbar sind.
Warum die wichtiger ist als jedes einzelne Werkzeug: Ohne sie fängt die KI bei jedem neuen Prompt wieder bei null an. Sie rät die Farbe. Sie rät die Schrift. Sie rät, ob sie React einbauen darf. Du korrigierst dieselben drei Dinge zum zwanzigsten Mal — und wunderst dich, warum die Seite nach KI-Brei aussieht.
Mit der Datei passiert das nicht mehr. Du schreibst die Regeln einmal auf, und ab da hält sich jede Antwort daran.
Vorlage zum Reinkopieren
Leg die Datei als CLAUDE.md direkt in deinen Projektordner. Fünf Minuten Arbeit, einmalig.
# CLAUDE.md — <Projektname>
## Projekt
<Ein bis zwei Sätze: Was ist das für eine Seite, für wen, was soll sie erreichen?>
## Leitprinzipien
- <z. B. Bilder statt Text — die Arbeit soll sprechen, wenig Copy>
- <z. B. Bewegung als Erlebnis, aber nie auf Kosten der Ladezeit>
- <z. B. ruhig und reduziert, kein visuelles Geschrei>
## Tech-Stack (verbindlich)
- <Framework> — nicht verhandelbar.
- <Styling>
- <Animation>
- <Sprache, z. B. TypeScript strict>
## Design-Tokens
- Hintergrund: <exakter Farbwert — nicht "weiß", sondern #EFEDE6>
- Text: <exakter Farbwert>
- Akzent: <exakter Farbwert, und wo er benutzt werden darf>
## Typografie
- Headlines: <Schrift + Gewicht + woher sie kommt>
- Fließtext: <Schrift + Gewicht>
## Was NICHT passieren darf
- <z. B. keine zusätzliche Bibliothek ohne Rückfrage>
- <z. B. keine Platzhaltertexte im fertigen Code>
- <z. B. keine Farbe, die nicht oben steht>
Der wichtigste Abschnitt ist der letzte. „Was NICHT passieren darf” spart dir mehr Zeit als alle anderen zusammen — weil er genau die Korrekturen abfängt, die du sonst jedes Mal von Hand tippst.
Und wenn dir während der Arbeit auffällt, dass du etwas zum zweiten Mal erklärst: schreib es in die Datei. Sie wächst mit dem Projekt.
Der Punkt
Es geht nicht um diese Namen.
Du kannst jede einzelne Station mit einem anderen Werkzeug besetzen. Andere Inspirations-Quelle, anderes Framework, anderer Hoster — die Kette funktioniert trotzdem.
Was zählt, sind zwei Dinge:
1. Jede Station hat genau eine Aufgabe und gibt sauber an die nächste ab. 2. Die Regeln stehen einmal geschrieben da, statt in jedem Prompt neu geraten zu werden.
Deswegen kann eine einzelne Person Ergebnisse liefern, für die sonst ein Team antritt. Nicht, weil die Tools so gut sind — sondern weil zwischen den Stationen nichts verloren geht.
Der häufigste Fehler ist nicht das falsche Werkzeug. Es ist, eine Station zu überspringen: ohne Richtung bauen, ohne Entwurf coden, ohne Prüfung abgeben. Jede übersprungene Station kommt später zurück — und dann teurer.
Fragen dazu? Schreib mir einfach auf Instagram. @made.by.prill · henry@madebyprill.com