Case study
The FuelTheFam case study.
FuelTheFam is our own product, a nutrition dashboard for sports families, built with Claude Code by the two of us, neither of whom writes code by hand. It is the worked example this course keeps returning to, and this page is the short tour of the build: what the product does, what runs where, what the model actually handles, and what running it costs.
The product, in one round trip
A parent photographs a plate, and about ten seconds later the meal is logged with its macros. A week of those logs becomes a per-member gap analysis, and the gaps become one grocery list for the household. Everything else on this page sits somewhere on that path.
- Photo · taken at the table
- Compressed · to a small JPEG on the phone
- App server · checks sign-in and the meter
- Claude Haiku · returns foods and macros as JSON
- Preview · the parent edits and confirms
- Saved · rows land in Postgres
- Week's end · analysis and a grocery list
The photo itself is never stored: it is compressed on the phone, parsed once on the server, and discarded, so only the structured rows survive. The most sensitive data store this product could have had simply does not exist, and Data, where information lives is the chapter on decisions like that one.
What runs where
The build is two addresses and five rented services. The marketing page and the app are separate deployments, plain files on one and every secret on the other, so nothing private sits anywhere near the public page, the separation Where software lives teaches.
A static page at fuelthefam.com with a click-through demo on sample data. Nothing private ever touches it.
The Next.js app at app.fuelthefam.com. Every model call runs in a server route here, never in the browser.
Auth plus Postgres. Row-level security is on for all four tables, so the database enforces family boundaries on every query.
Four calls: parse a typed meal, parse a photo, analyze the week, write the grocery list. The key lives only on the server.
The public nutrition database behind manual food search, reached through a server route that requires a signed-in user.
The platform records the app's uncaught errors with readable stack traces, and Resend sends password resets and signup notifications.
The model layer: four calls, two tiers
The division of labor is strict. The app’s code does all the arithmetic, from daily totals and weekly averages to each member’s targets, which come from a standard formula. The model handles recognition and suggestions: identifying the food in a photo, estimating the portion, naming the week’s gaps, and proposing what to buy. Each call states a role, its boundaries, and the exact JSON it must return, which is the pattern Get output you can build on teaches.
| The call | Runs | Model | What comes back | The guard around it |
|---|---|---|---|---|
| Parse a typed meal | Every log | Haiku 4.5 | Foods, portions, and macros as fixed JSON | Preview screen before anything saves |
| Parse a meal photo | Every log | Haiku 4.5 | Same JSON, from the image | Compressed upload, size cap, same preview |
| Weekly gap analysis | On demand | Sonnet 5 | Top three gaps with meal suggestions | Language rules; results cached for an hour |
| Grocery list | After analysis | Haiku 4.5 | A categorized list with reasons and swaps | Budget and kid-friendly guidance in the prompt |
The split between tiers came from trial rather than a benchmark chart: extraction runs on the small fast model, and the one judgment call runs on the big one. Choose the model you ship walks you through drawing that line for your own build.
What $40 a month buys
Four habits hold the bill near the cost of a family dinner: the expensive model runs only on the rare judgment call, analysis results are cached for an hour and reused until new logs arrive, photos are compressed on the phone before they travel, and an 800-token ceiling keeps every parse reply short. The machinery for charging money exists too, a 10-log monthly meter and plan gates on the expensive features, and all of it sits behind a flag that is still off, because the beta exists to find out what the product is worth before we design the price.
What this case shows
- Two people who do not write code by hand shipped a working AI product in 16 days for about $40 a month.
- Every hard moment in the build was a decision rather than a coding problem: choosing the model, drawing the boundaries, setting the price, judging the legal risk.
- Most of the stack is rented: hosting, sign-in, database, and the model are services, and the build is mostly the wiring and the rules between them.
- Nothing the model produces is saved automatically: every AI-parsed meal passes a preview the parent edits and confirms before anything lands in the database.
The chapters this build leans on hardest are here on this site: Data, where information lives, Get output you can build on, Choose the model you ship, Run the pre-flight, and Write your Build Plan and ship.
The full version of this case study lives on our flagship site, with the model-choice timeline, the boundary work around minors, the instrument-by-instrument audit, and the list of what we would fix next.
Read the full case study on our flagship site ↗Facts on this page were verified against the FuelTheFam repository and the live product on July 26, 2026, and against the month’s bills on July 23, 2026. Model names and costs go stale quickly, so lean on the decisions rather than the numbers.