Project Case Study
My Kitchen Board
A guest-first family meal planner and kitchen display. Plan a week of meals at the times a household actually eats, turn that week into one aggregated grocery list, and prop a tablet in the kitchen to show what is cooking next. Next.js 16 and Supabase, with an IndexedDB guest mode that works before anyone signs in.
View Live Project →Overview
My Kitchen Board is a family meal planner and kitchen display. The landing page states it in one line, "The week's meals. One happy kitchen.", and the promise under it is smaller than most planning tools make: "A little planning. A lot less what's-for-dinner."
The product is currently in Beta, free, and deliberately account-optional.
The Problem
Meal planning apps usually assume three things that real kitchens do not honour. That dinner happens at dinnertime. That everyone in the house eats the same thing. And that a visitor will create an account before they have seen anything work.
A household actually looks like this: breakfast at 7:00 for one child and 7:30 for another, two dishes at 6:00 PM that together are "dinner", a plan that is mostly the same every week, and one person doing the shopping for all of it. My Kitchen Board is built around that shape rather than around a tidy grid.
Key Product Decisions
1) Guest-first, not sign-up-first
The planner opens on a seeded sample week held in IndexedDB. It can be edited, cleared, and used indefinitely with no account; the landing page says so twice, because it is the main objection to overcome: "No account required · Saved on your device."
Signing in with Google is framed as one specific upgrade (the same kitchen on a phone and on a tablet), not as the price of entry.
2) Meals at real times, for real people
A meal is scheduled at an arbitrary household-local time, may overlap with another meal, and targets any combination of family members, including members who have no account and never will. Two dishes at 6:00 PM read as one dinner rather than as a conflict.
3) One grocery list that actually adds up
The week collapses into a single list. Duplicate ingredients merge, quantities scale to the servings planned, and every line keeps its provenance: which recipe version, on which occurrence, contributed it. Quantities are canonicalised with decimal.js (grams for mass, millilitres for volume, units for count), so scaling a recipe to 1.5 servings does not quietly drift.
4) Recipes that keep their history
Recipe versions are immutable. Editing a recipe creates a new version, and a plan that was already made keeps pointing at the text it was planned from. Materialized occurrences deliberately do not auto-pin to the newest version, so last Tuesday's dinner stays what it was.
5) A screen that belongs on a counter
The display view is built for a tablet left standing in the kitchen: today's meals in time order, serving sizes already adjusted, and timers built into the cooking steps. It is a different reading distance from the planning screens, and it is laid out as one.
6) Recurrence, because most weeks repeat
One-time, daily, every-N-day, weekly, every-N-week, and selected-weekday recurrence are all supported, so a standing Taco Tuesday is entered once rather than fifty-two times.
What This Means for the Business
The real product, before any sign-up: The full planner runs on the visitor's own device with no account and no connection needed, so the first visit is the actual product rather than a demo.
One kitchen on every device: Signing in keeps the same plans on a phone and a tablet, and each household's data is kept strictly separate from every other household's.
Sharing a recipe shares only the recipe: Published recipes open for anyone as fast public pages, but show no author, household details or comments, and never open a door to private data.
Accurate amounts at the right times: Quantities scale precisely without drifting, meal times follow the household's own time zone, and the core logic and main user flows are covered by automated tests.
Installs like an app: The browser offers to install it on the home screen, and going offline shows a clear explanation instead of a browser error.
What This Case Study Demonstrates
Designing an offline-first product where the guest path is the product, not a trial
Keeping a domain layer framework-free so two storage backends can share it exactly
Modelling immutability and provenance so a past plan stays true after the recipe changes
Getting decimal-safe quantities and timezone-correct scheduling right at the bottom of the stack
Treating CSP, RLS, and public-page exposure as design decisions rather than deployment checkboxes
Live: https://www.mykitchenboard.com/
Role: Solo delivery (product → domain → schema and RLS → PWA → brand)
