Recipe Platform
Minimum Viable Pantry
Stock the pantry once. Cook from it indefinitely.
Minimum Viable Pantry is a Sky Forward Design venture that started at a founder's own kitchen table, with the twenty minutes that disappear between "what's for dinner?" and knowing the answer. It inverts how recipe sites work: the pantry is defined first, and nothing gets published that can't be made from it alone. 75 shelf-stable staples, a catalog kept deliberately small, and a published evidence trail behind every claim — with the central promise enforced by the compiler rather than by editorial care.
The Problem
The failure isn't knowledge, it's the twenty minutes before dinner. You scroll a recipe site past the ads and the life story, hunting for the ingredient list. You check the fridge. Then the freezer. Then you're googling substitutions and learning that no, there isn't one. Time's gone and you still don't know what you're making.
The fix had to come before the recipes: settle on one small, shelf-stable pantry up front, then only publish dishes that can be made from it. Plant-based, because that premise clears the most dietary restrictions at once. That turns a nice promise into a hard constraint — and hard constraints are exactly the sort of thing software should be enforcing.
The ingredient list is the trap
Pick something that looks good and you find out, four lines in, that it needs a store run you weren't planning to make.
Substitutions rarely exist
The internet's honest answer to a missing ingredient is usually that there isn't a good one. Better to never be missing anything.
Fresh food spoils
Good intentions turn into slimy spinach in the crisper. Shelf-stable and frozen keep the plan alive through a bad week.
Deciding is the work
An infinite recipe library is not a feature when the real question is just "what am I making tonight?"
Guarantees the Build Enforces
The interesting engineering here isn't the recipe pages — it's that the product's promises are compiler-enforced rather than editorial policy. Recipes are content-collection entries that reference pantry ingredients by id, so the guarantees are checked at build time and a violation fails the deploy instead of shipping quietly.
The pantry guarantee
A recipe naming an ingredient that isn't in the 75-item pantry fails the build. There's no second tier and no "optional" ingredient to hide behind.
Single-source quantities
Method prose never hand-types an amount. Steps carry ingredient tokens and a custom remark plugin stitches in the quantity from frontmatter, so the steps can't drift from the ingredient list.
Unit and sidecar validation
A recipe using a unit its ingredient has no gram conversion for fails the build, as does a cost or shelf-life file missing a row for any pantry item.
Citations that can't rot
Metric badges and the evidence page read from one shared dataset, and a research reference that doesn't resolve fails the build — a badge and its receipt can never disagree.
Typecheck, unit tests, and the build all run in CI before any deploy, so these checks gate production rather than warn about it.
The Site
Because the pantry is settled, the site can do the thing a recipe archive can't: just tell you what you're having. The home page opens with tonight's dinner already picked — makeable from what you already own, and already known to be good — with two alternates if the mood is wrong. Nobody has to decide.
Everything else is built for that same directness. The recipe browser layers search, meal, time, cuisine, and dietary filters with live cross-filter counts; the pantry page presents all 75 staples as a ranked list, a chart, or full detail cards; and every recipe stitches its quantities into the method steps so nobody scrolls back to check an amount.
Readers can also make the pantry their own: removing an item strikes it from the list and hides its recipes everywhere on the site, and the printable shopping list re-adds itself around whatever survives.
A Catalog, Not an Archive
Most recipe sites are archives thousands deep, which quietly asks every visitor to wonder whether they've landed on the two-thousandth-best chili. This one is curated the other way around: publish a small number of dishes and make all of them worth cooking. Most of the ongoing work isn't adding recipes — it's improving the ones already there.
Every recipe earns its place
31 dishes today, each one something the author actually cooks. A recipe that isn't good enough gets fixed or cut, never buried in a search index.
Cooking notes go back in
Feedback from actually making a dish is edited straight into the recipe, and the revision is logged where readers can see it.
Revisions count as work
Each recipe carries a change log, and the sitemap stamps it with its last revision date so an improvement gets recrawled like a new page would.
The constraint says no
Two of the five originally planned recipes needed ingredients the pantry doesn't carry. The build blocked them, and they stayed blocked rather than bending the rule.
Research, Published as Receipts
Most food advice asserts a great deal and cites almost nothing, so nobody can check whether an ingredient earned its place. Here the pantry is curated by judgment and then backed by evidence — deliberately not the output of a scoring algorithm. An offline Python pipeline sifted 198,899 distinct ingredient names out of 2.2 million real recipes, then scored the finalists against eight published nutrition datasets and four dietary frameworks. Every number on the site links to the source it came from, and the scoring model's own weights and known weaknesses are published alongside it.
The dozen sources behind every badge:
Nutrition is computed at build time from per-100 g USDA figures and each ingredient's own unit-to-gram table, so per-serving calories and cost are derived rather than typed.
Technology
A static-first stack chosen so the guarantees can live in the type system and the site can stay fast, cheap, and durable.
Frontend
- Astro 5 (static output)
- Content collections + Zod
- Custom remark plugin
- Hand-written CSS design system
- Light + dark + print modes
Data & Tooling
- TypeScript
- Vitest unit + integrity tests
- Python analysis pipeline
- USDA FoodData Central
- Generated OG cards
Platform
- Firebase Hosting
- Cloudflare DNS
- GitHub Actions CI/CD
- PR preview channels
- Sitemap, RSS, IndexNow
Content as Code
The pantry and every recipe live in git as typed content-collection entries, so a change is reviewed, versioned, and validated like any other code change. There is deliberately no backend or CMS.
Derived, Not Typed
Recipe counts, per-serving nutrition, cost, and shopping-list quantities are all computed from the underlying data at build time. Adding a recipe moves the numbers across the site on its own.
Gated Deploys
Every push runs typecheck, unit tests, and the full build before Firebase Hosting is touched. Pull requests deploy to noindexed preview channels for review.
SEO & Syndication
Recipe structured data, per-recipe share cards, a sitemap stamped with each recipe's last revision date, an RSS feed, and IndexNow pings ship as part of the build.
Where It Stands
75
Pantry Staples
31
Recipes, Closed-Set
2.2M
Recipes Analyzed
12
Datasets & Frameworks
Live and shipping
Deployed at minimumviablepantry.com with a public changelog, and releasing continuously.
A promise that can't quietly break
The closed-set guarantee is checked on every build rather than trusted to a careful author.
Copy that can't drift
Quantities, counts, and nutrition figures are single-sourced, so the prose stays true to the data.
Zero-maintenance hosting
No database, no CMS, and no server to patch — a static bundle on a CDN, rebuilt on merge.
Fully cited
Every health and cost claim traces to a primary source, with the scoring model and its limits published in full.
Cheap to improve
Adding or revising a recipe is one markdown file; the browse page, filters, sitemap, and feed pick the change up automatically.
The founder's five-year-old asks for the red lentil dal by name, which is the only nutrition data anyone in that house cares about.