Domain System Architecture
A private kitchen operating system for cooks who want their recipes to stay theirs.
Nommable is an end-to-end culinary platform — recipes, collections, meal planning, pantry inventory with stock alerts, aisle-grouped shopping lists, batch cooking, and multi-provider AI with food photography — designed and engineered as a high-leverage TypeScript monorepo. It deploys to your own hardware with a single Docker Compose command, requiring zero external cloud dependencies.
Role & Scope
Systems Architect
Full-stack monorepo, UI system, SQLite/TypeORM schema, Better Auth
Scale
Full Platform
Recipes, meal planning, pantry matching, batch cooking & BYOK AI
Core Bet
Multi-Provider BYOK
Pluggable model abstraction across Gemini, OpenAI, Claude & Ollama
Impact
100% Sovereign
Shipped containerized single-container platform with zero subscription lock-in
Pulls scattered culinary content into a sovereign library.
Bookmarks, screenshots, message threads, and paywalled blog posts collapse into a searchable, categorized library. With Cloudflare and WordPress REST fallbacks, recipe extraction works reliably where typical scrapers fail. Because the stack is self-hosted, your recipes never get paywalled, altered, or sunset.
Turns meal schedules into smart grocery routes automatically.
Schedule meals across Breakfast, Lunch, Dinner, and Snack slots, and the shopping list auto-generates — categorized across ~180 grocery aisle keywords, consolidated by ingredient, and cross-referenced with pantry stock so you never buy what you already have.
The Consumer Lock-in Dilemma
Commercial apps either lock your data in or leave the heavy lifting to you.
Cooking at home is one of life's most persistent daily workflows, yet its software is broken into two frustrating extremes. Mainstream consumer tools (Paprika, NYT Cooking, Whisk) trap recipes inside proprietary walls, monetize personal meal habits through recurring subscriptions, and hold family collections hostage to price hikes or service shutdowns.
Conversely, the self-hosted open-source alternatives solve data ownership but stop at basic CRUD storage. Advanced meal planning, ingredient substitution, pantry expiration tracking, grocery routing, batch cooking, and modern generative AI assistance are left as unsupported exercises for the user. I wanted the complete end-to-end workflow in one refined, private application running on my own hardware.
Recipe detail view with dynamic serving multiplier, structured ingredient checklist, and culinary photography generated via Gemini 2.0 Flash / Imagen 3.
Strategic Trade-Offs: The Forks in the Road
Handling unstructured culinary web data, BYOK AI, and pantry telemetry.
A kitchen application is only as valuable as its underlying entity relationships. When translating messy real-world culinary web content into an operational grocery and meal planning engine, I evaluated and rejected two common industry shortcuts.
Unstructured Free-Text Recipe Blobs
The Premise: Scrape unstructured markdown or plain text blobs directly into the database without normalizing ingredients into discrete entity fields.
Why It Failed: It crippled all downstream intelligence. You cannot scale serving sizes, detect pantry stock matches, or aggregate "1 diced onion" across three different recipes into a single grocery list item without strongly-typed entity records.
Mandatory Cloud AI Model Lock-In
The Premise: Hardcode an OpenAI-exclusive API wrapper into the backend to handle all recipe extraction, photography, and meal planning suggestions.
Why It Failed: It violated the core self-hosted ethos. Users have different privacy preferences, API keys, and local hardware setups. Hardcoding a single commercial provider creates external fragility and locks out local Ollama users.
Multi-Provider AI Abstraction with Fallback Normalization
I engineered a decoupled AI service layer supporting Google AI (Gemini 2.0 Flash / Imagen 3), OpenAI (GPT-4o, GPT-Image), Anthropic (Claude 3.5), and local Ollama instances, with admin-configurable Shared Instance Key or Per-User BYOK (Bring Your Own Key) modes. When importing recipes from URLs or text dumps, the system uses structured schema extraction with deterministic regex fallbacks. Fractional quantities ("1 1/2 tbsp", "a pinch") normalize into canonical measurements, and ingredients automatically map to an internal ~180-keyword grocery category dictionary for aisle grouping—all running with SQLite (better-sqlite3) for zero-latency local operations.
Full-Stack Product Architecture
Four engineering milestones from PRD to production single-container release.
Relational Entity Modeling: Typing culinary domains in a TypeScript monorepo
Designed the entity architecture connecting recipes, collections, meal schedules, shopping lists, pantry items, and user feedback. Built with Express and TypeORM on top of SQLite (better-sqlite3) for immediate local data persistence without running a separate database server. Integrated Better Auth for secure session management, password hashing, and granular multi-user permissions (Shared Household Library vs. Per-User Private mode).
Weekly Meal Planning & Smart Pantry Telemetry: Reducing food waste
Meal planning fails when the interface creates calendar friction. I architected a responsive week view supporting multi-recipe slots across Breakfast, Lunch, Dinner, and Snacks with optional meal timestamps ([HH:MM]). The pantry layer tracks inventory stock levels, expiration countdowns, and low-stock alerts. Crucially, the Recipes view features a dedicated "Suggested from your pantry" recommendation band displaying exact match badges (Uses 5 of 6 pantry ingredients), immediately solving the "what can I cook tonight without shopping?" dilemma.
Automated Aisle Routing & Batch Cooking Wizard: Supermarket ergonomics
Shopping lists auto-populate from scheduled meal plans or manual inputs via a pinned quick-add bar with one-tap recent item chips. A keyword-matching algorithm categorizes ~180 common grocery items into collapsible supermarket aisle sections (Produce, Dairy, Meat/Seafood, Pantry, Frozen, Bakery, Beverages, Household). For meal prep enthusiasts, a guided 3-step Batch Cooking wizard calculates portion scaling, maps local calendar prep days, and bootstraps Freezer-Friendly batch storage timelines.
Multi-Provider AI Abstraction & BYOK Architecture: Flexible intelligence
Built a unified AI orchestration client supporting OpenAI, Anthropic, Google Gemini, and Ollama with live model discovery, 1-hour caching, and manual override fields. Features include recipe generation from scratch, intelligent ingredient substitutions ("out of buttermilk? use milk + lemon juice"), and culinary food photography powered by Google Gemini 2.0 Flash / Imagen 3 or OpenAI GPT-Image models. Users can supply their own keys (BYOK) or leverage a shared instance key configured in Admin Settings.
Velocity & Production Scale
A production-grade culinary system running on private hardware.
Nommable ships as a single-container Docker image orchestrating the React frontend, Express API, SQLite database, and multi-provider AI connectors. It provides granular household collaboration controls, an in-app bug and feedback widget with an admin triage inbox (/admin/feedback), and built-in SMTP email presets for inviting family members.
Gemini, Claude, OpenAI, Ollama
Automated Grocery Aisle Classifier
Self-Hosted Docker Single Container
Granular Shared or Private Library
Systems Prototyping Reflection
Spec discipline turns personal tools into enduring platforms.
The danger when building self-hosted software is letting feature ideas metastasize into half-finished experiments. With Nommable, I enforced strict specification discipline: writing comprehensive PRDs in Claude Code, defining normalized entity schemas first, and layering capabilities in sequential order—storage and URL ingestion first, then meal planning and pantry telemetry, then aisle routing, and finally pluggable AI models.
Because each layer rested on clean database contracts rather than ad-hoc frontend state, the application evolved naturally into a production-grade platform that my household uses every single day. Building working software in code is not about replacing engineers; it is about building deep empathy for system constraints and proving that high-density software can feel effortless.