Building this website as a content pipeline

This website is a content pipeline first and a website second. Every product page, app listing, and article you're reading renders from Markdown files in the repository. No CMS, no database, no admin panel.

Why Git-based content

One founder, technical team, content that's code-adjacent:

• Version history for free — every article edit is a diff
• Agent-editable — AI coding agents can write and revise content the same way they write code
• No recurring complexity — no CMS bill, no API keys, no webhook debugging at 11pm
• Review flow — content changes go through the same PR review as code changes

For a company whose journal is a first-class product, treating content as code isn't a gimmick — it's the natural architecture.

The pipeline

Content lives in content/:

content/
├── products/      # 8 SaaS products
├── apps/          # mobile apps
├── open-source/   # open-source projects
└── journal/       # articles & product stories (MDX)

Each file is frontmatter + MDX. A typed loader reads the directory at build time:

export const getAllProducts = cache((): Product[] =>
  readCollection('products').map(({ slug, data, body }) => ({
    slug,
    name: str(data.name, slug),
    // ...
  })),
);

Articles compile through MDX with remark/rehype plugins — GFM for tables, slugged headings, and highlight.js for code blocks. Everything renders on the server. The client gets HTML and zero kilobytes of markdown tooling.

The part that surprised us

The schema does editorial work. Because every product's frontmatter requires status, category, and a timeline, writing a content file forces the questions: what is this, actually? Is it live or building? What happened when? Bad product pages become structurally hard to write.

The structure of your content system shapes the quality of your content. Design the schema like an editor, not a database admin.

Trade-offs we accepted

• Writing requires a Git commit — fine for us, wrong for a team with non-technical editors
• No scheduled publishing — we merge when it's live
• Media management is manual — images live in /public

For v1 of a company like this one, it's not even close: Git-based wins.