Alex OS homepage journey engine
The CMS-driven journey + orbit engine powering the public homepage.
- Category
- CMS & Web
- Tech stack
- Next.js
- React
- MySQL
- FastAPI
- Metrics
- 2 visible journeys
- Sections, headings and prompts all CMS records
- Role
- Design + build
Content
The engine behind the journey homepage: journeys and per-journey sections live as CMS records, and the frontend assembles the experience from them. Picking a journey re-prioritises the content, swaps the headings, and hands the assistant a journey-specific brief — all without a deploy.
Problem
One static homepage cannot serve visitors with different intents — evaluating the work, exploring the systems, or reading the ideas behind them.
Decisions
Journeys and their sections are CMS records; the TypeScript defaults exist only as a fallback for when the database is unreachable. That distinction earned its keep more than once — the live configuration was in the database, so editing the code defaults would have changed nothing on the site.
The orbit spheres were part of the original design and are now switched off: the redesigned hero does the same job with less machinery, and the orbit records stay in the database rather than being deleted, so the decision is reversible.
Limitations
A journey is only as good as the content placed in its sections — a section pointing at a content type with nothing publishable renders as nothing at all, which is exactly what happened to the evidence section before its entries carried a method.
Outcome
The homepage reorganises around a chosen journey — hero, headings, sections and assistant prompts are all CMS-configured.
How this was built
Built with AI assistance (Claude Code). The architecture, the decisions and the trade-offs are mine; a lot of the implementation was written in pair with the model. I work this way deliberately — it's why one person can run a system this size — and the reasoning behind every call here is documented above.