Privacy choices

This site may send the owner a minimal page-visit notice with page, browser, device type, and resolution. If you accept analytics, it can also remember an anonymous visit/session ID and collect richer engagement signals.

Read the privacy notice
Expertise

Dynamic CMS Architecture

Designing configurable content platforms where content types, fields, sections, journeys and presentation are managed through the CMS.

Problems I solve
Hardcoded content types, Repetitive frontend templates, Inflexible homepage sections, Content model changes requiring code releases, Disconnected CMS and AI systems
Approach
Use a content-type registry, Store configurable fields and relationships generically, Normalize content into generic frontend and AI models, Keep sections configurable from the CMS, Support migrations rather than destructive deletion
Strengths
Generic content-type registry (content_types/content_type_fields/content_items) with zero hardcoded per-type models, A generic content_relationships table used for every relationship, in either direction

I work on CMS architectures that avoid hardcoded content models and rigid frontend sections. Content types, fields, permalinks, relationships, homepage sections and presentation rules can be configured from the CMS, while the frontend and reasoning layer consume a generic schema.

This CMS itself is the proof: content types, journeys, relationships and homepage sections are all rows in a database, not hardcoded models — adding Expertise and Skills as new types required no schema change.

Consolidating overlapping content types (Discoveries, Guides, Resources, Builds) into a cleaner set without losing any existing content.

Explore with Alex OS

A CMS where content types, fields, relationships, and homepage sections are database rows — so adding a new type requires no code change.

Dynamic CMS Architecture

Most CMS setups hardcode content models in application code, meaning any structural change — a new field, a new type, a new homepage section — requires a code release. This architecture inverts that: content types, fields, permalinks, relationships, and presentation rules are all stored generically and consumed by a schema-driven frontend and reasoning layer. The CMS itself is the live proof: Expertise and Skills were added as new content types with no schema migration.

How the architecture works

The core tradeoff

Generic schemas trade some query simplicity for structural flexibility. The payoff: adding Expertise and Skills as content types was a data operation — rows inserted, no application code touched. The current focus is consolidating overlapping types (Discoveries, Guides, Resources, Builds) into a cleaner set without data loss, which is the kind of refactor this architecture is built to support.

Verifiable proof

The homepage renders entirely from CMS-configured content types — no hardcoded sections. The journey and orbit engine powering it (Alex OS homepage journey engine) reads directly from those rows. Adding a new content type is documented as a data operation, not a deployment: content types are rows, not code. The schema-driven approach is explained in full in 'Schema-driven CMS architecture'.