Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Organization repository · verify with a repository file
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
iPhone-first meal planning, recipes and grocery price tracking for a couple. Next.js 16, Supabase Postgres with RLS, Google Gemini; built with Claude Code.
Plan it, price it, cook it. An iPhone-first web app (installable PWA) that a couple uses every day to plan meals, cook from recipes, track grocery prices across stores and build the shopping list, with AI that reads recipes from photos and estimates nutrition.
Try it: open the app and tap Try the demo: a shared demo kitchen with sample recipes, a planned week and price history, reset daily (how it's built).
What it does
Plan: a Monday-to-Sunday week with four spots a day (Breakfast, Lunch, Snacks, Dinner). Each spot offers only that meal's recipes. Each day shows Calories and Macros per person. This week's groceries adds up every ingredient (scaled to the servings planned), skips what's already in the kitchen, estimates the cost at your best prices, and adds it all to the list in one tap. Meal prep shows what to batch-cook and which ingredients to prep once.
Recipes: grouped by meal, with favorites and "regulars" (recipes you plan often) first. Recipes come from:
a website link, read from the page's schema.org recipe data, with no AI;
photos of a cookbook, magazine or recipe card, read by Google Gemini;
or typing.
Open a recipe to cook from your phone (with the screen kept awake), tick ingredients In stock, and add what's missing to the list. Estimate with AI fills in calories and macros.
Grocery: one shared list with big checkboxes, an In stock kitchen inventory that stays in sync with recipes and the list, and a price book. Every price is kept as history and compared by unit price, so a 5 lb bag and a 2 lb bag compare fairly. Each item shows its best price, its cheapest store right now, and its price trend.
Partner sharing: a married couple shares everything through an invite-only household (at most two people), enforced by the database.
Personal by design: sign-up is capped at 25 accounts, enforced by Postgres (0025).
Food emojis next to every item and ingredient (🍗 🍚 🥚), worked out from the name.
How it was built: AI-assisted engineering
I built Dialed Kitchen with Claude Code as an AI pair programmer. I owned the product and the engineering decisions:
the features and how each screen should work, tested on my own iPhone;
the architecture, the data model and the security model, each written up as a decision record with the alternatives considered;
reviewing every change and verifying it in the browser at phone size against the live database;
a professional delivery pipeline: a branch and pull request per change, CI that blocks merging until format, lint, type check, tests, build and a security audit all pass, versioned database migrations, and Dependabot updates tested one at a time.
Inside the product, AI is used where it earns its place, with guard rails: Google Gemini reads recipe photos and estimates nutrition (see AI features).
Architecture
Layer
Choice
Why
UI and server
Next.js 16 (App Router), React 19 Server Components and Server Actions, TypeScript (strict)
One codebase; data access and secrets stay on the server, and little JavaScript ships to phones
Styling
Tailwind CSS v4 with named design tokens
One source of truth for colors; text contrast is checked by a test
Database and auth
Supabase: Postgres, row-level security, Google sign-in (PKCE)
Real relational data; the database itself enforces who can see what
AI
Google Gemini (server-side only), structured JSON output, model fallback chain
Reads recipe photos and estimates nutrition on the free tier
Validation
Zod at every trust boundary: forms, URL parameters, fetched pages, AI replies, database rows
Types aren't validation
Hosting and CI
Vercel (Node 24), GitHub Actions, Dependabot
Every push is checked; every merge to main deploys
Request flow, with a check at each layer: UI → Server Action (Zod validation and sign-in check) → server-only data access (the user's own session, never a service key) → Postgres row-level security, the final guard even if app code has a bug.
Code layout:features/<feature>/ holds each feature's components, actions (writes), queries (reads) and schemas. lib/ holds pure, unit-tested logic (pricing, units, nutrition, plan rules). lib/server/ holds server-only infrastructure. supabase/migrations/ holds versioned SQL.
Every table carries household_id with row-level security. Composite foreign keys ((id, household_id)) stop rows from pointing at another household's data. Unit price and best price are computed from history, never stored, so they can't go stale. The week's shopping list, its cost and the meal-prep totals come from one SQL function, so they always agree.
Security
Strict Content Security Policy with a per-request nonce (no inline scripts or styles in production), plus HSTS, nosniff, COOP, frame blocking and a tight Permissions-Policy.
Row-level security on all 12 tables, column-level grants (the app can't set household_id), and check constraints for every invariant (46 in all).
Server-side auth only: no database client in the browser; HttpOnly, SameSite, Secure cookies; Google sign-in starts from a POST with an Origin check (CSRF).
SSRF-safe link import: https on port 443 only, and every resolved address is checked inside the connection's own DNS lookup, which closes DNS rebinding. Redirects are re-checked at each hop, with time, size and type limits. Sites that block apps get a clear message; nothing tries to get around them.
AI guard rails: keys only on the server; every reply is validated and range-checked; prompts treat text inside photos as data; a 40-a-day per-person limit is counted atomically in Postgres (advisory lock); photos are shrunk in the browser (which strips GPS data) and never stored.
Code scanning: GitHub CodeQL analyzes every push and pull request; its first finding (incomplete HTML sanitization) was fixed with a regression test. Secret scanning with push protection blocks committed keys.
Supply chain: a production dependency audit in CI, GitHub Actions pinned to commit SHAs, and Dependabot with written hold-back rules (0024).
AI features
Feature
How
Recipe from photos
Up to 3 photos, resized on the phone, sent to Gemini (multimodal) with a JSON schema; the answer is validated with Zod and fills an editable form; nothing saves on its own
Nutrition estimate
Gemini estimates per-serving calories and macros from the ingredients; any impossible value rejects the whole estimate
Reliability
A chain of free models: overloaded or slow models fall through to the next, a bad key stops at once, with per-model timeouts and a total time budget
Cost control
A shared 40-a-day limit per person, counted in Postgres
Quality
296 automated tests (Vitest). 116 of them run against real Postgres (PGlite, Postgres compiled to WebAssembly) with every migration applied, testing row-level security as real users: partners can share, strangers see nothing, nobody can forge or move rows.
CI on every pull request: production security audit, Prettier, ESLint, TypeScript type check, all tests, and a production build.
Accessibility: WCAG AA text contrast enforced by a test that reads the CSS, 48px tap targets, 17px+ text, labels on every control, and meaning never shown by color alone.
cp .env.example .env.local # fill in the Supabase URL and publishable key (and optionally a Gemini key)
npm install
npx supabase link --project-ref <your-project-ref>
npx supabase db push # applies the migrations in supabase/migrations
npm run dev # http://localhost:3000
npm test # unit and database tests
npm run lint && npm run typecheck && npm run build
Roadmap
0. Project setup, design tokens, CI, first deploy
1. Google sign-in and app layout (Plan · Recipes · Grocery tabs)
1b. Partner sharing: invite-only, for a married couple
2. Stores, items, prices: unit price, best price, history
3. Grocery list and shopping mode
4. Recipes entered by hand
4b. In stock: kitchen inventory synced with recipes and the list
5. Recipe import from a website
6. Recipe import from a photo
7. Weekly meal planner
7b. Calories and macros per day on the plan
8. Meal plan → grocery list with estimated cost
8b. Recipes sorted by meal (the Plan picker offers only that meal)
