This website as a product: how I scoped, built, and maintain daventhill.ch
Treating my own portfolio as a real product — a data-driven architecture, an SEO/AEO layer, and an AI-assisted workflow I use to keep it current.
Problem
A job search needs an asset that proves capability, not just claims it. A generic template or a static PDF turned into a webpage says nothing about whether I can actually own a digital product end to end — so I treated my own portfolio as a product, not a brochure.
Approach
I built this site on a data-driven architecture: a single TypeScript source of truth for my profile plus a markdown knowledge base, both rendered through an i18n layer into fully static, bilingual EN/DE pages, layered with an SEO/AEO structure (schema.org JSON-LD, a dedicated llms.txt for AI answer engines, per-page OG images) and a performance and accessibility budget. I maintain it with the same discipline I'd apply to any product I own: a written vision, a structured review process across content, UX, and SEO, and a running decision log — increasingly run through an AI-assisted, multi-agent workflow that I direct and sign off on.
Outcome
The result is a fast, accessible, bilingual site that's citable by AI answer engines and has been iterated on in the open, cycle by cycle, the same way I'd run a product roadmap. This case study is itself the proof — it documents the exact site you're reading it on.
Deep dive
Why I treated my own portfolio as a product
A resume is a claim. A live product is proof. I’m applying for Product Owner roles, so I built and run this site the way I’d run any product I owned: a written vision and target audience, a defined set of non-goals, a review cadence, and a running record of what shipped and why. The decision log behind this site reads like a lightweight product roadmap, because that’s exactly what it is.
That framing shapes everything below — this isn’t “look, I can code a website.” It’s “here is how I scope, prioritize, ship, and iterate on a product end to end, and you can watch me do it, because the product is the site you’re reading right now.”
Architecture: one source of truth, two languages, many surfaces
The site’s content lives in exactly one place per language: a typed profile file (profile.ts / profile.de.ts) for structured facts — experience, case studies, skills — plus a markdown knowledge base for longer-form explainers. Everything else is generated from that single source: the case-study index, the homepage sections, the skills page, per-page OpenGraph images, the llms.txt file for AI crawlers, and the schema.org structured data on every page.
Keeping structured facts and prose separate, but both flowing through the same i18n layer, means I add a fact once and it’s correct everywhere it’s used — in both languages, on every surface — instead of hunting down five places to update after a change.
Process: how this site actually gets improved
I don’t just ship changes ad hoc. I maintain a living vision document (mission, audience, voice, guardrails), and every improvement cycle follows the same loop: revisit the vision, run a structured review across content, UX/accessibility, and SEO/AEO, decide what to prioritize, ship it, and log the decision with its reasoning.
What makes this loop practical to run largely on my own is that I’ve built it around an AI-assisted, multi-agent workflow: specialist review passes propose changes in isolation, I reconcile and prioritize what they surface, and nothing ships — let alone goes live — without my explicit sign-off. I own the process; the AI tooling accelerates it. That’s the same relationship I’d want between any Product Owner and the tools their team uses.
From commit to daventhill.ch
Every change goes through the same pipeline: a commit on a feature branch, an Astro build that statically renders every EN/DE page plus the SEO/AEO layer, a Vercel preview deploy I review, and — only after I explicitly approve it — a production deploy to daventhill.ch.
Nothing reaches production without a human decision gate. For a site tied directly to my job search, that’s a deliberate guardrail, not an oversight.
What this proves
This case study isn’t a description of a past project — it’s a live one. The architecture, the process, and the AI-assisted workflow described above are the ones that produced the page you’re reading. If you want to see product ownership in action rather than take my word for it, this is it.
FAQ
- How do you automate website maintenance with AI agents?
- Automate website maintenance by giving separate AI agents narrow, single-discipline roles — one for content, one for UX and accessibility, one for SEO/AEO — and having each review the site and propose focused changes independently. A human orchestrator then reconciles the proposals, prioritizes, and approves before anything ships. This site is maintained with exactly that loop.
- What is a multi-agent AI content workflow?
- A multi-agent AI content workflow assigns each part of a website's upkeep to a specialized agent instead of one generalist prompt. Specialist agents — content, UX, SEO — each produce focused, reviewable proposals, and a human merges them and signs off. Splitting the work by discipline scales quality review far beyond what a single manual pass can cover.
- Can a website be fully automated without losing quality control?
- Yes — the safeguard is a human-in-the-loop approval gate. Let automation handle the heavy lifting (review passes, drafting, checks, and builds), but require an explicit human decision before production. Keeping the final sign-off manual is what stops an automated pipeline from publishing low-quality, inaccurate, or off-brand changes.
- How do you make a website citable by AI answer engines (AEO)?
- For answer engine optimization, structure the site so machines can quote it: schema.org JSON-LD (Person, CreativeWork, FAQPage), an llms.txt endpoint that maps content for AI crawlers, and question-based FAQ content that answers directly and stays quotable out of context. AEO is about being the clean, structured source ChatGPT, Perplexity, and Google AI Overviews can cite.
- What website architecture is easiest to keep up to date?
- A single source of truth. Keep structured facts in one typed data file and long-form content in a markdown collection, then generate every page, language, and metadata surface from it. Update a fact once and it is correct everywhere — no hunting through templates — which is what makes frequent, low-risk updates, whether manual or AI-assisted, practical.
Working on something similar?
Let's talk about data and AI driven product decisions for your team.
Get in touch