vittls

What it is.

vittls is a meal-planning system that generates a complete week of heart-healthy dinners with full prep schedules, equipment parallelism, and automatic omnivore and vegetarian protein swaps. Sunday cooking becomes a coordinated operation rather than a guessing game.

The product is split. Free meal plans are available to everyone, with full planning and prep-schedule functionality. AI-generated plans, where the system writes a fresh week from your household's constraints, sit behind a subscription.

Why it exists.

The inefficiency of cooking dinner every night struck me as a problem worth solving with AI. Every dinner is a small re-planning exercise: what do we have, who is around, what equipment is free, what gets prepped while what cooks. vittls does the planning once for the whole week, with the schedule explicit and the equipment conflicts already resolved.

How it works.

The free product handles the planning surface: the week view, the prep schedule, the household-level constraints (number of eaters, dietary preferences, equipment available), and the protein swap logic. None of that requires AI. It requires careful data modeling and a thoughtful UX. Households with limited time and many kids do not need a chatbot. They need a plan that works.

The paid tier is where the model earns its keep. Claude Opus 4.7 with extended thinking generates a fresh weekly plan from the household's constraints. The call runs server-side from a Supabase Edge Function so the API key stays out of the browser. Each generation runs around 47 cents, with a five-dollar weekly budget cap per household so the cost is bounded even if a user regenerates aggressively. Single-meal regeneration, when it ships, will route to Sonnet instead, since the smaller scope does not need Opus.

Cross-device sync uses Supabase Realtime so a parent updating the plan from their phone shows up on the tablet in the kitchen instantly. Authentication is email-and-password via Supabase Auth, with Row Level Security enforcing household-scoped data access at the database layer rather than at the application layer.

Stack.

Frontend

React 18 with TypeScript strict mode, Vite, React Router v6, Zustand for client state, vanilla CSS with custom-property theming (light and dark from a single token set)

Fonts

Self-hosted via @fontsource: Fraunces (display), Inter (sans), JetBrains Mono (mono)

PWA

vite-plugin-pwa for service-worker and offline support, planned, not yet wired

Backend

Supabase end to end: Postgres with RLS, Auth, Realtime for cross-device sync, Edge Functions (Deno) for server-side LLM calls and email

Hosting

Cloudflare Pages for the frontend, auto-deployed from GitHub. Same edge runtime as the company's other surfaces, no separate vendor relationship to manage

AI

Claude Opus 4.7 (`claude-opus-4-7`) with extended thinking on medium effort for weekly plan generation. Claude Sonnet 4.6 (`claude-sonnet-4-6`) reserved for single-meal regeneration. ~$0.47 per Opus generation, $5 weekly budget cap per household

Status.

Heavily in development. A working prototype exists but is not fully plumbed. The free product is the priority for first launch; the AI generation tier follows once the free tier is stable. Public timeline intentionally not committed until the prototype hardens. The product domain at vittls.app will activate alongside the first public release.