Building this blog: why JSON over a CMS

For a developer portfolio, the content layer should serve two goals: easy to edit for the developer, and easy to extend when requirements grow. A CMS like Prismic is great for teams; for a solo developer writing occasional technical articles, it's overkill.

Why JSON

• Zero external dependencies or API calls at build time
• Structured content blocks are typed — the renderer can't silently fail
• Easy to add new block types (images, embeds, diagrams) without changing the schema
• Git history tracks every content change

The content block model

Each article is an array of typed blocks: paragraph, heading, subheading, code, list, quote. The renderer is a simple switch statement. Adding an image block later means adding one case — no CMS schema migration, no API changes.

type Block =
  | { type: 'paragraph'; content: string }
  | { type: 'heading'; content: string }
  | { type: 'code'; language: string; content: string }
  | { type: 'list'; items: string[] }
  | { type: 'image'; src: string; alt: string; caption?: string };

Start with the simplest data model that solves the problem. You can always migrate to a CMS when the content outgrows JSON.