The Deceptive Dish

The problem

A recipe site is mostly content, and content sites decay quietly. Pages get renamed and the links to them break without anyone noticing. Recipes drift out of whatever shape the templates expect, so one missing field breaks a page months after it was written. And a site that is almost entirely text and photographs should not need a server running permanently to hand them out.

The solution

A statically generated site where recipes are structured content rather than hand-written pages. Each recipe is validated against a schema when the site builds, so a malformed or incomplete one fails the build instead of reaching the web; the recipe pages, the listings, the category filtering, the sitemap and the feed are all derived from that same content rather than maintained separately. The build runs type checking, a unit test suite and a link checker that walks the generated output and fails if any internal link points at a page that was not produced. Pushing to the main branch is the deployment.

Technical implementation

The Deceptive Dish collects familiar puddings, cakes and suppers rewritten to use very little fat, so that food people actually want to eat still works for someone who has to avoid it. It is a small site by design. The interesting part is not its size but what it took to make it stay correct without anyone maintaining it.

Content as data, not as pages

Every recipe is a structured record rather than a hand-written page: ingredients, method, timings, category, and the dietary claims that recipe makes. A schema describes what a valid recipe looks like, and the site will not build if one does not match it — a recipe missing a field fails at build time rather than rendering a broken page weeks later.

Everything a visitor sees is derived from that content. The recipe pages, the index, the category filtering, the seasonal section, the sitemap and the feed are all generated from the same records, so adding a recipe is one file and never a round of edits across the site.

Dietary tags are deliberately not inferred. A recipe is tagged only with what it actually claims, because a wrong tag on a site people use for dietary reasons is worse than no tag at all.

A build that refuses to ship broken output

Deployment is a push to the main branch, which means the checks in front of it are the only thing standing between a mistake and the live site. The build runs type checking across the project, a unit test suite, and a verification step that walks the generated output and follows every internal link, failing if any of them points at a page the build did not produce. Renaming a recipe therefore breaks the build rather than the site.

Three architectures

The site began as a React front end, moved within days to ASP.NET Core MVC with a custom crawler that rendered the application out to static HTML, and was rebuilt as a statically generated site on a new domain in October 2026.

The middle design is the instructive one. It worked — the crawler produced genuine static output — but it meant running and maintaining a web application purely in order to render pages that never changed per visitor. The current design reaches the same result as a build step rather than a server, which removed the application, the crawler and the runtime from the system entirely. The content survived all three changes unaltered, which is the argument for keeping content as data in the first place.

Hosting

Static files on Azure Static Web Apps, deployed from a pipeline on the main branch, with DNS and certificates in front. There is no server-side application and no database, so there is nothing to patch, scale, or wake up.