Featured project / Fed Forager
From dinner to deployment.
A conversational meal-planning product built around household context, structured recipes, and the practical work of getting dinner on the table.
Last reviewed
On this page
The problem
Meal planning is a coordination problem as much as a recipe problem. Preferences, household context, recipes, and a grocery list need to stay connected. A chat interface is useful only if the result becomes something people can act on.
Fed Forager grew from a real household planning workflow into a dedicated application. My work spans the product, application architecture, and its self-hosted release process.
The application
The stack combines a FastAPI backend, async SQLAlchemy and Alembic, PostgreSQL, and a Next.js/React frontend. Household boundaries and database permissions matter because a conversational workflow still operates on structured, private state.
flowchart TD accTitle: Fed Forager application layers accDescr: A browser frontend talks to an API backed by PostgreSQL. Authentication and worker services are separate responsibilities within the application deployment. Browser["Next.js browser interface"] --> API["FastAPI application"] Auth["Authentication service"] --> API API --> DB["PostgreSQL / household data"] Worker["Background worker"] --> DB
This is an application-layer overview. It intentionally separates the product from the shared public reverse proxy described in Architecture.
A release is more than a container restart
The documented alpha release uses immutable application images and explicit database migrations. The release process captures a recovery point, checks the schema and row-level security, and starts services through individual gates.
That matters because the host also serves other applications. Updating Fed Forager should not accidentally replace the shared Caddy edge or recreate an unrelated database volume.
Release verification includes readiness and revision checks, anonymous-access denial, public routes, and a period of observation. Authenticated product workflows still need their own acceptance checks; a healthy container is not proof that every user journey works.
Recovery is part of the product
The application has PostgreSQL dump jobs and scheduled restore testing. A backup-status record and a restore-test result answer different questions: whether an artifact was produced, and whether a tested artifact could be used.
The engineering lesson is to keep those checks separate and visible. “The backup timer ran” is weaker evidence than “the expected revision is serving requests and a database restore was tested.”
Current state
Fed Forager is a deployed closed alpha. Billing, inventory, and voice work exist on development branches beyond the documented production release. They are ongoing work, not presented here as shipped capabilities.