Seb Builds

Seb Builds is the public build surface behind sebmer.com. It turns active work into project pages, build logs, notes, metadata routes, and agent-readable context files.

The site exists because private work logs are not enough. Projects move quickly, and without a public memory layer the story disappears into Git commits, local notes, agent transcripts, and deployment chores. Seb Builds gives that work a cleaner public shape: project pages for the long-lived context, notes for dated progress, and metadata surfaces for people and agents that want to inspect what is going on.

What the site contains

• Project pages for active products, experiments, and infrastructure.
• Build logs that capture concrete dated changes without leaking private details.
• Static routes for notes, projects, RSS, sitemap, robots, llms.txt, and llms-full.txt.
• A public About surface and profile JSON for Sebastian Mertens.
• A small CLI foundation so the same public content can be inspected from developer workflows.
• A GitHub Pages deployment path for sebmer.com.

What changed in the recent commits

The recent local commits show the site becoming more than a starter portfolio. It gained GitHub Pages deployment, CNAME handling, public JSON content, a CLI package, the sebmer.com domain wiring, an About page, project narratives, accessibility improvements, and richer logs.

The first pass was useful but too thin. It proved the structure worked, but the project pages still read like placeholders in several places. The current direction is to make every project page feel like a proper living case study: enough context to understand the product, enough recent work to feel current, and enough boundaries to stay public-safe.

Why it matters

A builder site should not only show finished launches. It should also preserve the messy middle in a readable way. That includes infrastructure projects, local-first desktop tools, client-adjacent systems, research stacks, and experiments that are still becoming products.

Seb Builds is also a forcing function. When a project page looks stale, that is useful feedback: the public story has fallen behind the actual work. Updating the site turns scattered commits into a narrative, and that narrative makes it easier to decide what to build or explain next.

Editorial model

The site separates short and long memory. Build logs are intentionally concise: they answer “what happened on this date?” Project pages should answer the deeper questions: what is this, why does it exist, what changed recently, where is it going, and what is intentionally not public?

That model matters because many of the projects touch private workflows. The public copy needs to be specific enough to be valuable, but abstract enough to avoid exposing credentials, customer data, raw operational paths, or fragile internals.

Current direction

The next version of Seb Builds should feel more like an active product operating log: richer project narratives, clearer homepage hierarchy, better cross-linking between notes and projects, and eventually more media around the builds. The content layer is now good enough to support that; the remaining work is keeping it alive.

Public boundary

Seb Builds publishes public context only. It intentionally avoids raw private transcripts, secrets, local paths, client-private exports, trading rules, and implementation details that would create security or privacy problems.