Why I Validate Portfolio Content at Runtime

The projects are data, not component copy

This portfolio has 26 project records with publication state, media, different section types and route data. Once that content drives pages, a malformed record can become a broken route or renderer instead of just a typo.

TypeScript is not enough for loaded content

TypeScript only checks code that passes through the compiler. Content can still arrive from JSON, imports or an admin tool, so runtime validation is useful at the content boundary.

const result = projectSchema.safeParse(rawProject);

if (!result.success) {
  throw new Error("Invalid project content");
}

Use the same rules before rendering

The useful part is not the schema by itself. The same content rules can be checked before a project is published and again during release verification, so invalid fields fail before the public build.

It makes changes safer

When I change the content model, the validation and TypeScript errors show which queries, editors or renderers also need attention. That is much easier to reason about than discovering a missing field in production.