Recipes and Kitchen Tools
Build a recipe or kitchen tool for home cooks, meal planners, or a small food business. The material is real and pasteable: schema.org recipe markup on public recipe sites, the Open Food Facts API, USDA FoodData Central, and recipe datasets like RecipeNLG or Food.com on Kaggle. The constraint: the app has to accept the same kind of recipe or food input in at least two different formats, one of which you did not design.
The theme
The brief — background and project ideas
Recipe and kitchen software today splits into recipe blogs with a print button, meal-kit apps that assume a subscription, and grocery list apps that only work if you type every item by hand. Nutrition trackers want meals logged one at a time. Almost nothing takes a recipe as it actually exists in the wild, whether that is a link, a photo, a spreadsheet row or a scrawled card.
Example project ideas include recipe scalers that take a pasted URL or raw text and rescale quantities for a new serving size or pan, grocery list generators that merge, convert and deduplicate ingredients across several recipes into one shoppable list, nutrition lookup tools that compute macros for a full recipe from its ingredient list, substitution and allergy tools that swap ingredients for a dietary need, meal planning dashboards that turn a week of recipes into a shopping list and a prep schedule, pantry inventory tools that suggest recipes from what is on hand, recipe archive tools for storing, tagging and searching recipes pulled from many sites, small kitchen admin panels for menu, pricing and ingredient costing, unit conversion tools for cups, grams and oven temperatures, step-sequencing tools that turn a recipe into a timed checklist, leftover and food-waste tools that suggest recipes from expiring items, cost-per-serving calculators, potluck and event planners for coordinating dishes and dietary restrictions, receipt parsers that match grocery line items against a shopping list, and recipe card generators for printing or sharing. The material is real and free: schema.org recipe markup embedded on public recipe pages, the Open Food Facts API, USDA FoodData Central, and recipe datasets like RecipeNLG or Food.com on Kaggle.
Two hours is enough for one input path done well plus a second format bolted onto the same pipeline. Get one real recipe parsing and rendering before adding the second format. Leave out accounts, meal history, social features and multi-user households. Unit conversion and ingredient parsing are the hard part: fractions, ranges, and ingredients with no quantity at all. Fetching or caching real recipe pages and public datasets is fine. A handful of recipes you hand-typed as your only test case is not.
Projects should solve a real user problem and show a path toward something someone would actually use. Get one recipe parsed end to end, ingredients, quantities and steps, before worrying about a second format. A thin entry is a text box preloaded with one demo recipe and a scale button that only works on that one recipe. A strong entry takes a pasted URL with schema.org markup and a raw pasted block of text through the same parser, and still produces a usable list when a quantity is missing or a unit is unfamiliar. If you are unsure where to begin, start with a recipe scaler that accepts a pasted URL, a pasted block of raw text, and an ingredient with a vague amount like a pinch or to taste, and build from there.
Directions other builders might take — examples only, never a menu to pick from:
- Scaling and conversion — A recipe URL or pasted text in, ingredient quantities rescaled for a new serving size or unit system out.
- Shopping and pantry — Multiple recipes or a pantry list in, one consolidated grocery list or a pantry-match suggestion out.
- Nutrition and cost — An ingredient list in, a per-serving nutrition or cost breakdown out using public food data.
- Planning and admin — A week of recipes or a small kitchen's menu in, a prep schedule, order sheet or costing dashboard out.
- Parsing and recovery — A recipe photo, receipt or messy pasted text in, a structured ingredient list out even when quantities are vague.
- Open / wildcard — anything else in recipes and kitchen tools that accepts two real input formats.
How the judges score this theme
The public rubric is the same every sprint. This is what each axis means for this theme in particular.
The parser has to run live on a real pasted URL, block of text, or file at demo time, with the ingredient list or output changing to match what was actually entered. A build wired to one hardcoded demo recipe reads faked, whatever the UI looks like.
The constraint is two real input formats through one pipeline, not the word recipe. An app that only accepts one fixed textarea format reads literal, 7-12. An entry that runs a pasted URL with schema.org markup and a raw pasted block of text through the same logic is a real interpretation, 19 and above.
Care shows in accurate unit conversion, a clean readable ingredient list, and sensible handling of odd amounts. A logo, a color theme or a login screen are not where the points are.
The obvious version is a single-format scaler on a clean recipe. Ambition is handling the messy real cases: ranges, fractions, ingredients with no quantity, or merging several recipes into one list. Calling a model to parse text is not ambition by itself, what you check and correct afterward is.
Winners
“Parsing and scaling quantity ranges ('2-3 cloves garlic' correctly scaling to '4-6 cloves garlic') while preserving qualitative descriptions like 'pinch of salt'.”
A winning entry accepts a real recipe or food record in a format the builder did not invent and still produces useful output.