Persönliche Portfolio-Website

Mein persönliches Portfolio begann als Website, die ich in Figma gestaltete und in Webflow entwickelte, um meine Arbeiten, Leistungen und Erfahrungen als Webflow-Entwickler zu präsentieren.

Mit der Weiterentwicklung des Portfolios wollte ich mehr Kontrolle über Codebasis, Hosting, Content-Verwaltung und zukünftige Entwicklung gewinnen, ohne das bestehende Design und die responsive Nutzererfahrung aufzugeben. Daher wurde die Webflow-Website exportiert und zu Hostinger migriert. Dort bildete sie die Grundlage für eine zunehmend individuell angepasste Entwicklungsumgebung.

Später wurde die Website um Eleventy als Static-Site-Generator, wiederverwendbare Nunjucks-Templates, Markdown-basierte Projektinhalte und Pages CMS erweitert. Dadurch lassen sich Fallstudien verwalten, ohne HTML manuell zu bearbeiten. Git und GitHub kamen für Versionskontrolle hinzu. GitHub Actions erstellt heute nach dem Commit von Inhalts- oder Codeänderungen automatisch die Eleventy-Website und stellt die Produktionsdateien auf Hostinger bereit.

Das Ergebnis ist eine fortlaufend weiterentwickelte, selbst gehostete Portfolio-Plattform. Sie verbindet die in Figma und Webflow geschaffene visuelle Grundlage mit einem schlanken CMS, strukturierten Inhalten, Versionskontrolle und einem automatisierten Deployment-Workflow.

Ich behandelte das Projekt als schrittweise Weiterentwicklung statt als vollständigen Neuaufbau. Das bestehende Webflow-Portfolio verfügte bereits über eine etablierte visuelle Identität, responsive Struktur und funktionierende Interaktionen. Deshalb lag die Priorität darauf, diese Grundlage zu erhalten und gleichzeitig nach und nach mehr Kontrolle über Website und Entwicklungsworkflow zu gewinnen.

Im ersten Schritt exportierte ich die Webflow-Website und richtete eine saubere lokale Entwicklungsstruktur ein. Anstatt das bestehende Frontend zu ersetzen, behielt ich das generierte HTML, CSS, JavaScript, die Assets und Interaktionen bei und passte beziehungsweise erweiterte sie dort, wo es für das unabhängige Hosting erforderlich war.

Die nächste Phase konzentrierte sich darauf, das Portfolio leichter pflegbar und erweiterbar zu machen. Eleventy wurde als schlanker Static-Site-Generator eingeführt. Wiederverwendbare Nunjucks-Templates und Markdown-basierte Inhalte trennten Projektinformationen von der Darstellung. Pages CMS kam als Bearbeitungsebene hinzu, sodass Fallstudien über eine visuelle Oberfläche erstellt und aktualisiert werden können, während die Inhalte direkt im GitHub-Repository gespeichert bleiben.

Abschließend automatisierte ich den Veröffentlichungsworkflow. Änderungen im Hauptbranch von GitHub lösen GitHub Actions aus. Der Workflow installiert die Projektabhängigkeiten, erstellt die Eleventy-Website und überträgt die generierten Produktionsdateien über ein dediziertes FTP-Konto, das auf das öffentliche Verzeichnis des Portfolios beschränkt ist, auf den Hostinger-Server.

Durch diesen schrittweisen Ansatz konnte sich das Portfolio von einer gehosteten Webflow-Website zu einer unabhängig verwalteten Plattform entwickeln, ohne das ursprüngliche Design aufzugeben oder unnötige Infrastruktur einzuführen.

Die Entwicklung begann mit der ursprünglichen Webflow-Umsetzung. Das freigegebene Figma-Design wurde mit dem Layout-System von Webflow in eine responsive Website übertragen und dort, wo zusätzliche Kontrolle erforderlich war, durch eigenes HTML, CSS und JavaScript ergänzt.

Im weiteren Projektverlauf wurde die Webflow-Website exportiert und in eine lokale Entwicklungsumgebung überführt. Frontend-Struktur, Styles, JavaScript, Bilder, Animationen und weitere Assets blieben erhalten, während das Projekt für eine unabhängige Entwicklung und Bereitstellung neu organisiert wurde. Anschließend wurde die Website zu Hostinger migriert. Damit entfiel die Abhängigkeit vom Webflow-Hosting, während die bestehende Frontend-Erfahrung erhalten blieb.

Die selbst gehostete Version wurde um individuelle Funktionen erweitert. Das Kontaktformular nutzt einen PHP-Endpunkt zur serverseitigen Verarbeitung und Cloudflare Turnstile zum Schutz vor Bots. Bestehende interaktive Komponenten und das responsive Verhalten wurden beibehalten und bei Bedarf weiter verfeinert.

In der nächsten größeren Entwicklungsphase kam Eleventy als Static-Site-Generator für Portfolio-Fallstudien hinzu. Projektinhalte wurden von der Darstellung getrennt und als strukturiertes Markdown gespeichert. Wiederverwendbare Nunjucks-Templates erzeugen konsistente Fallstudienseiten. Pages CMS wurde mit dem GitHub-Repository verbunden und bietet eine visuelle Oberfläche zum Erstellen und Bearbeiten von Projektinhalten, ohne Markdown oder HTML manuell ändern zu müssen.

Git und GitHub übernehmen die Versionskontrolle für Website-Code und CMS-verwaltete Inhalte. Anschließend wurde der Veröffentlichungsprozess mit GitHub Actions automatisiert: Jede relevante Änderung im Hauptbranch startet die Installation der Abhängigkeiten und einen Eleventy-Produktionsbuild. Danach werden die generierten _dist-Dateien über ein dediziertes FTP-Konto automatisch in das public_html-Verzeichnis des Portfolios auf Hostinger übertragen.

Mit diesem Entwicklungsworkflow gelangen zukünftige Fallstudien und Website-Verbesserungen über einen konsistenten, versionierten und weitgehend automatisierten Prozess von Content- oder Codeänderungen auf die Produktionswebsite.

Dieses Projekt hat den Wert einer schrittweisen Weiterentwicklung bestehender Websites bestätigt. Ein vollständiger Neuaufbau ist nicht automatisch erforderlich, nur weil sich die zugrunde liegende Architektur ändern soll. Das ursprüngliche Webflow-Frontend bot eine solide visuelle Grundlage. Dessen Erhalt ermöglichte die technische Weiterentwicklung, ohne bereits erfolgreiche Arbeit unnötig neu umzusetzen.

Die Abkehr vom Webflow-Hosting zeigte außerdem, wie wichtig die Trennung von Design, Inhalt und Bereitstellung ist. Nach dem Wechsel zum selbst gehosteten Betrieb konnte das Frontend weitgehend unverändert bleiben, während Eleventy, Nunjucks und Markdown gezielt dort eingeführt wurden, wo sie einen konkreten Nutzen boten: wiederverwendbare Templates und strukturierte Fallstudieninhalte.

Der Aufbau des CMS-Workflows verdeutlichte eine weitere wichtige Erkenntnis: Ein Content-Management-System benötigt nicht zwangsläufig eine klassische Datenbank oder ein Backend. Für ein Portfolio mit weitgehend strukturierten und selten geänderten Inhalten bietet die Kombination aus in GitHub gespeichertem Markdown und Pages CMS eine schlanke Lösung mit integrierter Versionshistorie und vollständiger Kontrolle über die Inhalte.

Ebenso wichtig war die Automatisierung der Bereitstellung. Manuelle Uploads sind zu Beginn handhabbar, werden jedoch schnell ineffizient, sobald Inhalte über ein CMS aktualisiert werden. Die Verbindung von Pages CMS, GitHub, GitHub Actions, Eleventy und Hostinger schuf einen wesentlich klareren Veröffentlichungsworkflow und reduzierte die manuellen Schritte bis zur Produktionsbereitstellung.

Das Projekt bestätigte außerdem, dass Technologien nach dem tatsächlichen Problem ausgewählt werden sollten, statt Komplexität um ihrer selbst willen hinzuzufügen. Die aktuelle Architektur bleibt bewusst schlank und bietet dennoch Content-Verwaltung, wiederverwendbare Templates, Versionskontrolle, automatisierte Bereitstellung, Sicherheit, Analysen und Raum für zukünftige Erweiterungen.

Da das Portfolio ein fortlaufendes Projekt bleibt, kann sich die Architektur mit neuen Anforderungen weiterentwickeln, ohne einen weiteren vollständigen Neuaufbau zu erfordern.