← Back to portfolio
Personal2026

A family recipe archive with no CMS

Family recipes live in a shoebox of index cards, someone's inbox, and a site that'll be dead in five years. I wanted an archive that outlives all three without anyone learning a CMS.

  • Astro
  • Content collections
  • Claude
  • Markdown

Outcome

A private cookbook site where adding a recipe means handing Claude a photo of a recipe card. No admin panel, no database, no login.

What's in it

  • Recipe content collectionTemplate

    A typed Astro schema that treats a recipe as structured data rather than a blob of text: ingredients grouped by section, an 11-value course enum, difficulty, prep and cook time, servings, cuisine, and country.

    Ingredients are an array of groups, each with an optional label, so 'For the dough' and 'For the filling' survive as structure instead of a bolded line in the middle of a list.

  • Provenance fieldsTemplate

    The fields that make it an archive rather than a recipe site: contributor, family branch, generation, origin, and per-person variations.

    Generation is an enum running great-grandparent to current. Variations carry an author and a note, so two people can disagree about how much garlic goes in and both versions persist with names attached.

  • recipe-converterSkill

    The entire content pipeline. Takes a URL, pasted text, or a photo of a handwritten card and outputs a schema-valid markdown file, filed into the right folder.

    This is what replaces the CMS. It paraphrases instructions rather than copying them, holds ingredient amounts exact, classifies course by how a dish is actually used rather than how the source tags it, and asks before guessing when a card is illegible.

The problem

Every family has the same three archives and all of them fail differently. The shoebox of index cards is authoritative and unsearchable. The email thread is searchable and unstructured. The recipe site someone set up in 2014 is structured and, at some point, gone.

I wanted one that survives, and the constraint that mattered most was this: the people contributing to it are not going to learn a CMS. If adding a recipe takes more than sending a photo, nobody sends a photo.

What I built

A static Astro site backed by a content collection, where every recipe is a markdown file with a typed schema, and the way you add one is by handing a photo to Claude.

There’s no admin panel because there’s no database. There’s no login because the site is private. The content pipeline is a skill file, and the storage layer is a git repo, which means the whole archive is greppable, diffable, and portable to whatever replaces Astro in ten years.

How it works

The schema does more work than a recipe site usually asks of one. Ingredients are grouped arrays rather than a flat list. Course is an enum with eleven values. Difficulty is defined by technique rather than time.

The fields I care most about are the ones a normal recipe site doesn’t have. contributor and familyBranch record who a recipe came from and which side of the family. generation is an enum from great-grandparent through current. variations is an array of author-and-note pairs, so a recipe can carry three people’s disagreements about it without any of them overwriting the others.

Adding a recipe means sending a photo of a card, a URL, or pasted text. recipe-converter reads it, fills the schema, writes the instructions in its own words rather than copying the source, and files it under the right folder. The rules that matter are encoded in the skill: exact ingredient amounts, no rounding, ask rather than guess when handwriting is unclear.

Why this is the interesting one

It’s the smallest build here and the one that best shows the pattern. A typed schema plus a skill that fills it is a content system, and it scales down to a family cookbook as cleanly as it scales up to a marketing site.

The part worth stealing is the inversion. Most sites put a CMS between a person and a schema, then spend years maintaining the CMS. This one puts a skill there instead. The schema stays strict, the input stays loose, and nobody has to learn anything to contribute.

If you want this kind of workflow running inside your team, that's the work I do.