Warum ich mir eine eigene Homepage mit Blog gebaut habe

Ich wollte schon länger einen Ort im Web haben, an dem meine Gedanken, Projekte und Learnings gebündelt auffindbar sind.

GitHub ist gut für Code. LinkedIn und X funktionieren für bestimmte Arten von Beiträgen auch. Aber jede Plattform hat ihre eigene Logik, ihre eigene Art von Aufmerksamkeit und am Ende auch ihre eigenen Grenzen. Gerade bei technischen Themen, längeren Gedanken oder Dingen, die ich später selbst wiederfinden will, ist das auf Dauer einfach nicht das gleiche wie ein eigener Ort.

Genau daraus ist meine Homepage entstanden.

Eigentlich war der ursprüngliche Gedanke erstmal recht simpel: Ich wollte eine eigene Portfolioseite. Einen Platz, auf dem ich mich, meine Projekte und ein bisschen von dem zeigen kann, was ich baue und wie ich denke. Nicht als sterile Visitenkarte, sondern eher als technische Basis mit etwas mehr Persönlichkeit.

Relativ schnell kam dann aber noch eine zweite Idee dazu: Wenn ich sowieso schon eine eigene Seite aufbaue, warum sollte dort nicht direkt auch ein Blog mit dran hängen?

Nicht, weil ich jetzt plötzlich „Content Creator“ spielen will. Sondern weil viele Dinge, die ich baue, teste oder lerne, sich nicht sinnvoll in einen kurzen Plattform-Post pressen lassen. Manche Themen brauchen mehr Raum. Manche Learnings sind erst dann wirklich nützlich, wenn man sie sauber aufschreibt. Und manche Gedanken will ich nicht in den Formaten anderer Plattformen verlieren, sondern an einem Ort sammeln, der wirklich mir gehört.

Nicht nur eine Homepage, sondern ein eigener Platz im Web

Für mich sollte die Seite von Anfang an mehr sein als nur ein Portfolio.

Klar, Projekte zeigen gehört dazu. Aber ich wollte auch einen Ort haben, an dem ich Hintergründe erzählen kann. Warum ich etwas gebaut habe. Welche Entscheidungen ich dabei getroffen habe. Was funktioniert hat und was eher nicht. Welche Tools sich für mich bewährt haben und welche eher nicht. Gerade als Entwickler gehört für mich mehr dazu als nur Code zu schreiben. Ich finde es wichtig, Dinge nicht nur irgendwie zusammenzubauen, sondern auch den Aufbau dahinter zu verstehen. Also wie Systeme zusammenspielen, wie Deployment funktioniert, wie Content gepflegt wird, wie Routing sauber aufgebaut ist, wie man Performance im Blick behält und wie aus einer Idee am Ende etwas wird, das tatsächlich nutzbar ist.

Genau deshalb war diese Homepage für mich nicht nur „eine Website“, sondern auch ein Projekt, an dem ich bestimmte Frameworks, Strukturen und Abläufe bewusst ausprobieren wollte.

Warum der Blog direkt mit dazugekommen ist

Der Blog war am Anfang nicht das Hauptziel, aber ziemlich schnell ein logischer Teil des Ganzen.

Eine Portfolioseite zeigt am Ende meistens Ergebnisse. Ein Blog zeigt eher den Weg dorthin. Und genau dieser Weg ist für mich oft fast interessanter als das Endergebnis selbst.

Ich beschäftige mich viel mit technischen Themen, Selfhosting, Docker, Compose, KI-Systemen, Agenten, eigenen Projekten und allem, was sich irgendwo zwischen Softwareentwicklung, Infrastruktur und Ausprobieren bewegt. Viele dieser Themen leben davon, dass man nicht nur sagt „ich habe etwas gebaut“, sondern auch erklärt, warum, wie und mit welchen Learnings.

Dazu kommt noch etwas ziemlich Praktisches: Plattformen wie LinkedIn oder X funktionieren komplett anders. Dort braucht man andere Texte, andere Längen, andere Einstiege. Das ist okay, aber ich wollte erstmal einen Ort haben, an dem Inhalte ausführlich und gebündelt liegen. Von dort aus kann man später immer noch plattformspezifisch arbeiten.

Der Blog ist also nicht einfach nur ein Zusatz. Er ist ein Teil der eigentlichen Idee.

Die technische Seite dahinter

Die Homepage selbst basiert im Frontend auf Astro.js. Das war für mich vor allem wegen Performance, Struktur und Ladezeiten interessant. Styling-seitig fließen unter anderem Ideen aus shadcn ein, aber natürlich in einer Form, die optisch zu mir und meiner Seite passt.

Gehostet wird das Ganze aktuell auf meinem Heimserver. Also wirklich selfhosted und nicht einfach nur irgendwo schnell zusammengeklickt. Gebaut wird über GitHub Actions, dann als Docker-Image in die GitHub Container Registry geschoben und anschließend per Docker Compose auf dem Server gezogen und gestartet.

Allein dieser Teil war für mich schon wichtig, weil ich nicht einfach nur das sichtbare Frontend haben wollte, sondern auch den Weg dorthin verstehen wollte. Also nicht nur „Website fertig“, sondern auch: Wie läuft der Build? Wie kommt das Image auf den Server? Wie spielt das Deployment mit dem Rest meiner Infrastruktur zusammen?

Noch spannender wurde es für mich beim Blog selbst.

Ich nutze dafür kein externes CMS, sondern arbeite an einem eigenen Dashboard, das diese Rolle übernimmt. Darüber kann ich Beiträge anlegen, bearbeiten und veröffentlichen. Titel, Kurzbeschreibung, Content in Markdown, Bilder und weitere Metadaten lassen sich dort pflegen. Wenn ein Beitrag öffentlich geschaltet wird, taucht er direkt im Blog auf, inklusive eigenem Slug.

Der eigentliche Content wird dabei aus Markdown in den finalen Beitrag überführt. Genau dieser Workflow war mir wichtig: Inhalte möglichst angenehm schreiben und pflegen, aber am Ende sauber auf der Website ausspielen.

Im Hintergrund dürfte dafür aktuell Supabase eine Rolle spielen, wobei das System an einigen Stellen noch im Ausbau ist. Und genau das finde ich ehrlich gesagt auch völlig okay.

Warum ich keine Standardlösung wollte

Natürlich hätte ich auch einfach irgendein fertiges CMS, ein Theme und einen gehosteten Baukasten nehmen können.

Das wäre schneller gewesen.

Aber genau das war nicht der Punkt.

Ich wollte verstehen, wie so ein System aufgebaut ist. Ich wollte ausprobieren, wie sich ein eigener Workflow anfühlt. Ich wollte nicht nur eine Seite haben, sondern auch lernen, wie sie technisch funktioniert und wie weit ich sie langfristig in meine eigene Richtung entwickeln kann.

Dazu gehört für mich inzwischen auch ganz offen der Einsatz von KI. Die Homepage ist nicht einfach nur klassisch von Hand entstanden, sondern auch mit Hilfe von KI bzw. über das, was viele inzwischen als Vibe Coding oder Vibe Engineering bezeichnen. Für mich ist das kein Widerspruch zu echter Entwicklung, sondern mittlerweile ein ziemlich normaler Teil moderner Softwarearbeit.

Wichtig ist nur, dass man nicht blind etwas zusammenwerfen lässt und dann so tut, als wäre damit alles erledigt. Der eigentliche Mehrwert entsteht für mich dann, wenn man versteht, was da gebaut wurde, warum es so funktioniert und an welchen Stellen man selbst eingreifen, umbauen oder verbessern muss.

Was daran unkompliziert war – und was überhaupt nicht

So ein Projekt sieht von außen meistens geradliniger aus, als es intern wirklich ist.

Klar, am Ende steht da eine Website. Aber sobald man eine Homepage, einen Blog, Routing, Slugs, Veröffentlichungslogik, Markdown-Rendering, Deployment, Hosting, Performance und eine Art eigenes CMS zusammenbringen will, wird es schnell deutlich detailreicher.

Gerade das Routing war nervig. Aber auch viele andere Punkte, die man am Anfang leicht unterschätzt: saubere Struktur, sinnvolle Verknüpfungen, Darstellung von Content, technische Erweiterbarkeit und die Frage, wie flexibel das Ganze später wirklich sein soll.

Genau solche Baustellen gehören für mich aber dazu. Sie sind nicht nur Nebenprodukt, sondern oft der Teil, aus dem die eigentlichen Learnings entstehen.

Worum es hier künftig gehen wird

Der Blog ist für mich kein starres Magazin mit festem Redaktionsplan.

Ich werde hier wahrscheinlich ziemlich spontan schreiben, je nachdem, was ich gerade baue, teste, zerdenke oder interessant finde. Aber thematisch wird es sich ziemlich klar um Dinge drehen, die sowieso schon ein Teil meiner Arbeit und meines Alltags sind:

• technische Projekte
• Selfhosting
• Docker und Docker Compose
• KI-Systeme und KI-Agenten
• Webentwicklung
• eigene Tools und Eigenentwicklungen
• Learnings aus echten Umsetzungen
• Gedanken zu Dingen, die beim Bauen meistens erst unterwegs sichtbar werden

Wenn spätere Beiträge auf frühere verweisen können, umso besser. Aber ich will mich hier bewusst nicht in einen künstlichen Veröffentlichungsplan pressen. Die Seite soll nicht nach Content-Maschine aussehen, sondern nach einem Ort, an dem echte Dinge landen.

Und ja, ganz nebenbei darf die Seite auch etwas zurückgeben

Ganz nüchtern betrachtet kostet Selfhosting Geld. Infrastruktur kostet Zeit. Und wenn man schon einen eigenen Ort im Web aufbaut, ist es aus meiner Sicht auch völlig legitim, über Dinge wie Monetarisierung nachzudenken.

Das ist nicht der Hauptgrund für die Seite. Aber es ist ein realistischer Nebenaspekt. Wenn sich so ein Projekt langfristig zumindest teilweise selbst tragen kann, ist das eher sinnvoll als verwerflich.

Der aktuelle Stand

Die Seite ist da. Der Blog ist angebunden. Das Grundsystem steht.

Aber fertig ist so etwas natürlich nie.

Es gibt noch Baustellen, Dinge, die ich verbessern will, und Teile des Dashboards, die sich weiterentwickeln werden. Genau das ist aber auch ein Teil des Reizes. Ich wollte keinen komplett abgeschlossenen Showroom bauen, sondern eine Grundlage, die mit meinen Projekten, Ideen und Learnings mitwachsen kann.

Am Ende ist diese Homepage für mich genau das geworden, was ich haben wollte: kein Platzhalter, kein reines Profil und keine externe Plattform, die bestimmt, wie meine Inhalte aussehen müssen.

Sondern ein eigener Ort im Web.