ProjectJuly 12, 2026

Alex CMS

A Next.js CMS with a fully dynamic content-type registry — no hardcoded post models — plus a journey-based homepage, an orchestrator workflow, and per-item content scoring.

Category: cms_web
Tech stack: Next.js, TypeScript, MySQL, mysql2
Metrics: 8 content types, Homepage fully CMS-driven
Role: Design + build

Content

Content types (Discoveries, Projects, Guides, Resources, Build Lab, Signals, Proof, Builds, Thinking, Experiments, Connect, Alex OS, Notes) are rows in a content_types table, not TypeScript models. Fields, validation, and display rules are also data. The homepage, navigation, and journey sections are resolved from that same data at request time — there's no code path that assumes a fixed set of content types.

Problem

A hand-coded content model means every new kind of content needs a schema migration and new frontend code. That doesn't scale for a site that keeps changing shape.

Architecture

Next.js 15 app with a MySQL-backed dynamic registry (content_types, content_type_fields, content_items), a six-stage orchestrator (Create/Improve/Verify/Publish/Learn/Automate), and journey/homepage config also stored as data (journeys, section_settings).

Decisions

Deliberately excluded Postgres/Redis/a vector DB from the CMS's own stack to keep the system of record simple — those live in Alex OS only, where they're genuinely needed for embeddings.

Limitations

Some content types created early on (Discoveries, Projects, Guides, Resources) were archived when the newer Experience types were introduced and had thin or empty field schemas until this content pass revived them.

Next steps

Keep building out real content across the revived types; tighten navigation to reflect all public content types.

Outcome

Fully dynamic content model with zero hardcoded types.

cmsnextjsmysqldynamic-contentproofimpactsystem

Internal Links

Keep exploring

Explore with Alex OS

Alex built a CMS where content types, fields, and display rules are database rows — so adding a new content type requires no code changes, only data.

The Problem

A hand-coded content model creates a hard dependency between schema and code. Every new content type — Guides, Signals, Experiments — would need a migration plus new frontend logic. For a site that keeps changing shape, that's a maintenance trap. The fix: make content types, their fields, and their display rules rows in a MySQL table, not TypeScript models.

How It Works

Key Decision: Keep the Stack Minimal

Postgres, Redis, and a vector DB were deliberately excluded from the CMS stack. Those tools live in Alex OS, where embeddings and semantic search genuinely need them. The CMS's system of record stays simple: Next.js + TypeScript + MySQL via mysql2. That tradeoff keeps the CMS auditable and easy to reason about, at the cost of features that belong elsewhere anyway. See how the CMS connects into Alex OS for the fuller picture.

Verifiable Outcomes

Thirteen content types — Discoveries, Projects, Guides, Resources, Build Lab, Signals, Proof, Builds, Thinking, Experiments, Connect, Alex OS, Notes — exist as rows, not code. Early types (Discoveries, Projects, Guides, Resources) were archived when Experience types launched, then revived in a content pass that also surfaced a concrete discovery: content fields are data, not code. The guide 'Add a new dynamic content type' documents exactly how to extend the model without touching application code.

Known Limitations

The revived early content types (Discoveries, Projects, Guides, Resources) had thin or empty field schemas before this content pass. Some gaps remain. Next steps are straightforward: fill out real content across the revived types and tighten navigation to reflect all public content types accurately.