Project deep dive
Personal Recipe Library - a low-friction home for recipes we actually use
This is an in-progress mobile-first recipe app I am building because my wife and I do not have one reliable place for the recipes we actually cook. The goal is simple: make saving a recipe fast no matter where it came from, then make it clean and easy to use later.
The idea
Recipes tend to pile up in the least useful possible way: bookmarked websites, cookbook pages, screenshots, notes, and things we vaguely remember making once. I wanted one small, practical app that could become the place for recipes we actually want to cook again.
The product principle is low friction. Recipe organization should not become another chore. Saving something should be quick, and the result should feel clean enough to browse, edit, and use while cooking.
What works now
- The mobile app and API are communicating successfully.
- Recipes can be created through the API, persisted in PostgreSQL, and retrieved again.
- The backend has separated Fastify routes, runtime request validation, and parameterized PostgreSQL queries.
- The database runs locally in Docker with persistent storage and version-controlled schema migrations.
Planned direction
- Share or import a recipe from a URL and turn the page into structured recipe data.
- Capture a recipe from a cookbook, recipe card, or printed page and extract it into an editable recipe.
- Add fast manual recipe creation and editing for the cases where typing is still the shortest path.
- Build the core library experience: browsing, search, favorites, recipe details, ingredients, instructions, and a focused cooking view.
Current technical approach
Monorepo structure
The project is split into a mobile client at apps/mobile and a Fastify API at apps/api, which keeps the product layers close without mixing their responsibilities.
Backend foundation
I am building the API myself with Node.js, Fastify, PostgreSQL, Docker, and node-pg-migrate so the data model, validation, and migrations are part of the product thinking from the start.
Recipe persistence
The current API supports GET /recipes and POST /recipes, backed by PostgreSQL and parameterized queries so created recipes survive server restarts and can be retrieved by the app.
Mobile-first use
The client is being built with React Native, Expo, Expo Router, and TypeScript because the real use case is phone-first: saving recipes quickly and using them in the kitchen.
What makes it interesting to me
- It starts with a real household problem instead of a generic demo prompt.
- The product challenge is restraint: make saving recipes easier without turning the library into a tagging and cleanup job.
- It gives me room to own the whole system, from mobile UX to API design, data modeling, local infrastructure, and eventual import workflows.
Why I included it here
It is still in progress, but it reflects the kind of software I like building: practical, personal, and useful enough that I want it in my own life. The technical work supports that goal, but the point is the product: one clean place for the recipes we actually use.