Comparison of publishing workflows: code → Git → deploy → live versus CMS → publish → live

Rebuilding the Lab Notebook: From Hardcoded Blog to Chronicle CMS

🎯 Objectives

Replace the original hardcoded blog workflow with a CMS-based system that enables fast, repeatable, and low-friction publishing.

⚙️ Previous System (Baseline)

The original site was built as a frontend-first React + Vite application deployed on Vercel.

Content handling:

  • Article metadata stored in local source code
  • Full article bodies embedded inside large React components
  • Publishing required code edits + Git + deployment

This created a developer-dependent workflow for writing.

The original frontend structure was generated using AI-assisted tooling. What launched quickly became difficult to maintain — the architecture prioritized speed of generation over long-term usability. The rebuild was not planned. It was necessary.

🔥 Problem

The issue was not visual design — it was publishing friction.

A single article update required:

  • Editing code
  • Manual formatting
  • Image placement adjustments
  • Commit → push → Vercel deploy

This caused the site to behave like a software project, not a lab notebook.

🛠️ Architecture Change

To remove this friction, the system was rebuilt with a CMS-first model.

Changes:

  • Introduced Sanity CMS as content backend
  • Defined structured post schema
  • Implemented AI Lab categories (Experiments, Projects, Field Notes, Archive)
  • Migrated rewritten articles into CMS
  • Connected frontend routes to Sanity data
  • Replaced hardcoded content with dynamic content pipeline

The CMS layer was codenamed Chronicle internally. A lab notebook should feel like one.

⚙️ New System

Current architecture:

  • Frontend: React + Vite
  • Hosting: Vercel
  • Content backend: Sanity (Chronicle)

Data flow:

Sanity (content)
→ frontend fetch
→ rendered pages (listing + article)

Publishing model:

  • Frontend changes → Git + Vercel
  • Content changes → publish in Sanity (no deploy required)

⚙️ Observations

The key issue with the original system was coupling writing with code.

The new system separates:

  • Content management (Sanity)
  • Presentation (frontend)

This reduces friction and improves scalability.

📊  Results

Current state:

  • Chronicle CMS running ✅
  • All articles stored in Sanity ✅
  • Homepage and article pages dynamically rendered ✅
  • Hardcoded blog architecture removed ✅

Publishing is now:

write → publish → live

💡 Key Learnings

  • AI-assisted tooling can accelerate frontend structure, but does not solve publishing workflow design
  • A publishing system fails if writing feels heavier than building
  • CMS separation is critical for long-term sustainability
  • Structured content scales better than embedded code
  • Taxonomy and site identity matter as much as tooling
  • The right architecture is the one you can actually use — not the one that launched fastest

📝 Notes

This transition was not a "blog redesign." It was an architecture correction.

  • The old system proved the site could launch
  • The new system makes it usable

🚀 Next Steps

  • Improve rendering strategy for machine readability
  • Evaluate CSR limitations vs pre-rendered approaches
  • Prototype Astro-based static rendering pipeline (Phase 2)
  • Validate content visibility via source inspection and link previews

✅ Closing

The old system proved we could launch. Chronicle proved we could continue.

✅ Research team credit:

EthanC + Motoko-chan + Codex-chan + Claude-chan (CEC)+ Lovable-chan, whose early contributions made this rebuild possible.