Was ich nach 30+ Website-Projekten anders mache

Wenn ich mir meine ersten Projekte heute anschaue, muss ich schmunzeln. Nicht weil sie schlecht waren, sondern weil ich vieles unnötig kompliziert gemacht habe. Nach über 30 Projekten ist mein größtes Learning simpel: Die besten Websites sind nicht die komplexesten, sondern die durchdachtesten.

Aufwand ehrlich einschätzen

Einer der größten Fehler am Anfang war, den Aufwand für Custom-Lösungen zu unterschätzen. “Das bauen wir schnell custom” klingt im Erstgespräch gut, aber in der Realität fressen solche Sachen extrem viel Zeit. Ein animierter Slider, der sich “ein bisschen anders” verhalten soll, oder ein Formular mit Logik, die das Tool nativ nicht kann. Jedes Mal dachte ich, das dauert vielleicht einen halben Tag. Am Ende saß ich zwei Tage dran.

Heute kalkuliere ich Custom-Aufwand bewusst großzügiger und hinterfrage vorher, ob es wirklich custom sein muss. In den meisten Fällen gibt es eine einfachere Lösung, die genauso gut funktioniert.

Nicht über das Tool hinausschießen

Website-Builder wie Webflow oder Framer sind extrem leistungsfähig, aber jedes Tool hat Grenzen. Und die sollte man respektieren, statt sie mit Workarounds zu umgehen.

In frühen Projekten habe ich regelmäßig versucht, Dinge zu bauen, die das jeweilige Tool so nicht vorgesehen hat. Das Ergebnis waren fragile Konstrukte, die beim nächsten Update Probleme gemacht haben. Oder Code, den außer mir niemand verstanden hat.

Heute bleibe ich bewusst nah an dem, was ein Tool nativ kann. Man kann den Status quo ein bisschen challengen, aber nur bei Projekten, wo das auch wirklich Sinn macht. Bei den meisten B2B-Websites geht es darum, Vertrauen aufzubauen und Anfragen zu generieren. Da braucht niemand experimentelle Animationen.

Sauber aufbauen statt extern einbinden

Früher habe ich gerne externe Scripts, Libraries und Snippets eingebunden. Copy-Paste von Stack Overflow, ein Codepen hier, eine Library dort. Das funktioniert erstmal, bis es nicht mehr funktioniert.

Wenn dann etwas kaputt geht, sitzt du da und debuggst fremden Code, den du nicht wirklich verstehst. Wartung wird zum Albtraum.

Mein Ansatz heute ist ein anderer. Wenn ich Custom Code brauche, baue ich ihn von Grund auf selbst. Ich habe mir dafür ein eigenes Setup aufgebaut, mit dem ich sauber arbeiten kann. Das dauert am Anfang vielleicht etwas länger, aber ich verstehe jede Zeile und kann alles problemlos warten.

CMS so minimal wie möglich

Ein starkes CMS verleitet dazu, es zu überladen. Am Anfang habe ich CMS-Strukturen gebaut, die alles abdecken sollten. Dutzende Felder, verschachtelte Referenzen, komplexe Filter.

Am Ende loggt sich der Kunde nach dem Launch ein und versteht nichts. Zu viele Optionen, zu viele Felder, zu viel Komplexität.

Heute halte ich das CMS bewusst minimal. Nur die Felder, die der Kunde wirklich braucht, keine “das könnte man irgendwann mal brauchen”-Felder. Wenn der Kunde nach dem Launch eigenständig Inhalte pflegen soll, muss das CMS intuitiv sein.

Struktur vor Design

Das letzte und vielleicht wichtigste Learning ist, dass eine saubere Projektstruktur mehr Zeit spart als jeder Shortcut.

Bevor ich die erste Seite baue, lege ich heute ein festes System an: einheitliche Namen für Klassen und Komponenten, wiederverwendbare Bausteine und klare Regeln für Abstände und Typografie. So bleibt ein Projekt auch nach Monaten wartbar und lässt sich sauber erweitern. Klingt technisch, hat aber einen direkten Effekt auf die Zusammenarbeit. Wenn ein anderer Entwickler das Projekt übernehmen muss, findet er sich sofort zurecht. Und auch für mich selbst ist es ein Unterschied, ob ich nach sechs Monaten ein sauber strukturiertes Projekt öffne oder ein Chaos aus generischen Klassennamen.

Keep it simple

Wenn ich die letzten 30+ Projekte in einem Satz zusammenfassen müsste: Einfach schlägt komplex. Immer.

Die Websites, mit denen meine Kunden am zufriedensten sind, sind nicht die mit den meisten Features. Es sind die, die klar strukturiert sind, schnell laden und es dem Besucher leicht machen, eine Anfrage zu stellen.