Diese Website als Produkt: Wie ich daventhill.ch konzipiert, gebaut und weiterentwickelt habe
Das eigene Portfolio als echtes Produkt behandelt — eine datengetriebene Architektur, eine SEO/AEO-Schicht und ein KI-gestützter Workflow, mit dem ich sie aktuell halte.
Problem
Eine Stellensuche braucht ein Asset, das Fähigkeiten beweist, statt sie nur zu behaupten. Ein generisches Template oder eine zur Webseite gewordene PDF sagt nichts darüber aus, ob ich ein digitales Produkt tatsächlich End-to-End verantworten kann — also habe ich mein eigenes Portfolio wie ein Produkt behandelt, nicht wie eine Broschüre.
Vorgehen
Ich habe diese Website auf einer datengetriebenen Architektur aufgebaut: einer einzigen TypeScript-Datenquelle für mein Profil plus einer Markdown-Wissensdatenbank, beide über eine i18n-Schicht in vollständig statische, zweisprachige EN/DE-Seiten gerendert, ergänzt um eine SEO/AEO-Struktur (schema.org JSON-LD, ein eigenes llms.txt für KI-Antwortmaschinen, seitenspezifische OG-Bilder) sowie ein Performance- und Barrierefreiheits-Budget. Ich pflege sie mit derselben Disziplin, die ich bei jedem Produkt anwenden würde, das ich verantworte: einer schriftlichen Vision, einem strukturierten Review-Prozess über Content, UX und SEO sowie einem laufenden Decision Log — zunehmend über einen KI-gestützten Multi-Agent-Workflow, den ich selbst steuere und freigebe.
Ergebnis
Das Ergebnis ist eine schnelle, barrierefreie, zweisprachige Website, die von KI-Antwortmaschinen zitierfähig ist und offen, Zyklus für Zyklus, weiterentwickelt wurde — genau so, wie ich eine Produkt-Roadmap führen würde. Diese Case Study ist selbst der Beweis: Sie dokumentiert genau die Website, auf der Sie sie gerade lesen.
Vertiefung
Warum ich mein eigenes Portfolio wie ein Produkt behandelt habe
Ein Lebenslauf ist eine Behauptung. Ein laufendes Produkt ist ein Beweis. Ich bewerbe mich auf Product-Owner-Rollen, also habe ich diese Website so gebaut und betrieben, wie ich jedes Produkt führen würde, das ich verantworte: eine schriftliche Vision samt Zielgruppe, eine definierte Liste von Non-Goals, ein Review-Rhythmus und ein laufendes Protokoll, was ausgeliefert wurde und warum. Das Decision Log hinter dieser Website liest sich wie eine schlanke Produkt-Roadmap, weil es genau das ist.
Dieser Rahmen prägt alles Folgende — es geht hier nicht um “Schaut her, ich kann eine Website programmieren.” Es geht um: “So gehe ich vor, um ein Produkt End-to-End zu scopen, zu priorisieren, auszuliefern und weiterzuentwickeln — und Sie können mir dabei zusehen, denn das Produkt ist genau die Website, die Sie gerade lesen.”
Architektur: eine Datenquelle, zwei Sprachen, viele Flächen
Der Content dieser Website liegt pro Sprache an genau einer Stelle: eine typisierte Profildatei (profile.ts / profile.de.ts) für strukturierte Fakten — Erfahrung, Case Studies, Skills — plus eine Markdown-Wissensdatenbank für längere Erklärungen. Alles andere wird aus dieser einen Quelle generiert: der Case-Study-Index, die Homepage-Abschnitte, die Skills-Seite, seitenspezifische OpenGraph-Bilder, die llms.txt-Datei für KI-Crawler und die schema.org-Strukturdaten auf jeder Seite.
Strukturierte Fakten und Fliesstext getrennt zu halten, aber beide durch dieselbe i18n-Schicht laufen zu lassen, bedeutet: Ich pflege einen Fakt einmal, und er stimmt überall dort, wo er verwendet wird — in beiden Sprachen, auf jeder Fläche —, statt nach einer Änderung fünf Stellen manuell nachzuziehen.
Prozess: Wie diese Website tatsächlich weiterentwickelt wird
Ich liefere Änderungen nicht einfach ad hoc aus. Ich pflege ein lebendiges Vision-Dokument (Mission, Zielgruppe, Tonalität, Leitplanken), und jeder Verbesserungszyklus folgt derselben Schleife: Vision erneut prüfen, strukturierten Review über Content, UX/Barrierefreiheit und SEO/AEO durchführen, priorisieren, ausliefern und die Entscheidung samt Begründung protokollieren.
Was diesen Loop praktikabel macht, obwohl ich ihn grösstenteils allein betreibe, ist, dass ich ihn um einen KI-gestützten Multi-Agent-Workflow herum aufgebaut habe: Spezialisierte Review-Durchgänge schlagen isoliert voneinander Änderungen vor, ich gleiche ab und priorisiere, was dabei zutage kommt, und nichts wird ausgeliefert — geschweige denn live geschaltet — ohne meine explizite Freigabe. Ich verantworte den Prozess; das KI-Tooling beschleunigt ihn. Genau diese Beziehung würde ich mir zwischen jedem Product Owner und den Tools seines Teams wünschen.
Vom Commit bis zu daventhill.ch
Jede Änderung durchläuft dieselbe Pipeline: ein Commit auf einem Feature-Branch, ein Astro-Build, der jede EN/DE-Seite plus die SEO/AEO-Schicht statisch rendert, ein Vercel-Preview-Deployment, das ich prüfe, und — erst nachdem ich explizit zugestimmt habe — ein Produktions-Deployment auf daventhill.ch.
Nichts erreicht die Produktion ohne ein menschliches Entscheidungsgate. Für eine Website, die direkt an meine Stellensuche geknüpft ist, ist das eine bewusste Leitplanke, kein Versehen.
Was das beweist
Diese Case Study beschreibt kein vergangenes Projekt — sie ist ein laufendes. Die Architektur, der Prozess und der oben beschriebene KI-gestützte Workflow sind genau die, die die Seite erzeugt haben, die Sie gerade lesen. Wer Product Ownership in Aktion sehen will, statt mir nur zu glauben, findet sie hier.
FAQ
- Wie automatisiert man die Website-Pflege mit KI-Agenten?
- Die Website-Pflege automatisiert man, indem man einzelnen KI-Agenten klar abgegrenzte, fachspezifische Rollen gibt — je einen für Content, für UX und Barrierefreiheit sowie für SEO/AEO — und jeden die Website unabhängig prüfen und gezielte Änderungen vorschlagen lässt. Ein Mensch als Orchestrator führt die Vorschläge dann zusammen, priorisiert und gibt frei, bevor etwas live geht. Genau nach dieser Schleife wird diese Website gepflegt.
- Was ist ein Multi-Agenten-Workflow für Content mit KI?
- Ein Multi-Agenten-Workflow weist jeden Teil der Website-Pflege einem spezialisierten KI-Agenten zu, statt alles über einen generalistischen Prompt zu lösen. Spezialisierte Agenten — Content, UX, SEO — liefern jeweils fokussierte, überprüfbare Vorschläge, und ein Mensch führt sie zusammen und gibt frei. Die Aufteilung nach Fachbereich skaliert die Qualitätsprüfung weit über das hinaus, was ein einzelner manueller Durchgang leisten kann.
- Kann eine Website vollständig automatisiert werden, ohne die Qualitätskontrolle zu verlieren?
- Ja — die Absicherung ist ein Human-in-the-Loop-Freigabeschritt. Die Automatisierung übernimmt die Fleissarbeit (Review-Durchgänge, Entwürfe, Checks und Builds), aber vor der Produktion ist eine ausdrückliche menschliche Entscheidung nötig. Die manuelle Endfreigabe verhindert, dass eine automatisierte Pipeline minderwertige, fehlerhafte oder markenfremde Änderungen veröffentlicht.
- Wie macht man eine Website für KI-Antwortmaschinen zitierbar (AEO)?
- Für Answer Engine Optimization strukturiert man die Website so, dass Maschinen sie zitieren können: schema.org-JSON-LD (Person, CreativeWork, FAQPage), ein llms.txt-Endpunkt, der Inhalte für KI-Crawler abbildet, und frageorientierte FAQ-Inhalte, die direkt antworten und aus dem Kontext gelöst zitierbar bleiben. AEO heisst, die saubere, strukturierte Quelle zu sein, die ChatGPT, Perplexity und Google AI Overviews zitieren können.
- Welche Website-Architektur ist am leichtesten aktuell zu halten?
- Eine Single Source of Truth. Strukturierte Fakten in einer typisierten Datendatei, Langtexte in einer Markdown-Sammlung — und daraus jede Seite, Sprache und Metadaten-Ebene generieren. Ein Fakt wird einmal aktualisiert und ist überall korrekt, ohne Templates zu durchsuchen. Genau das macht häufige, risikoarme Aktualisierungen — ob manuell oder KI-gestützt — praktikabel.
Arbeiten Sie an etwas Ähnlichem?
Lassen Sie uns über daten- und KI-getriebene Produktentscheidungen für Ihr Team sprechen.
Kontakt aufnehmen