Madklar is live on the App Store, with one authenticated MCP connector serving the mobile product and AI clients, plus product and price comparison across six grocery retailers.
The problem
Many people already ask their AI chat for meal suggestions. The answers can be useful, but the chat usually knows little about the household: who is home, what they prefer, what is in the pantry or what has already been planned.
Those details change. Purchases add stock, cooking consumes it, and moving a dinner changes the shopping requirement. The state must remain consistent after the conversation ends.
Madklar was built around structured household state. AI helps interpret a request and develop a proposal. The application manages the plan, calculations and resulting changes.
How we approached this
Attendance and recipe requirements create gross demand. Pantry stock is netted against it, and the remainder becomes shopping demand. Purchases add inventory; completed meals consume it. Changes and reversals follow the same model.
The logic is derived from material-requirements and inventory planning, adapted to a focused household product.
A shared, authenticated MCP connector exposes typed household, plan, pantry, recipe, history and retailer data. The iPhone app uses it for reads, writes and calculations. AI clients retrieve the same live state and request permitted actions through typed tools. This is structured retrieval over application state, without embeddings or a vector database.
AI suggestions pass through application validation and household approval before becoming shared state. Inventory calculations and identifiers remain deterministic, while typed contracts and concurrency controls protect updates.
Bring your own AI
Through the MCP connector, a household can bring its preferred MCP-capable client—ChatGPT, Claude or Mistral. The provided Madklar skill guide explains the available data and tools.
The client can work with the weekly plan, recipe library, pantry inventory and shopping flow. It retrieves current context, reasons across it and requests changes within those product boundaries. Authentication scopes household access; typed contracts, deterministic calculations, concurrency controls and user approval govern what becomes shared state.
The result is a balanced use of raw model intelligence in production: the model reasons, while Madklar supplies live domain context, permitted actions and system boundaries. External AI clients remain first-class product clients alongside the iPhone app.
Choosing the in-app model path
We evaluated Apple Foundation Models on the device and built a native Swift integration to test the approach. The available context capacity was too limited for household preferences, attendance, pantry stock, recipes and the current plan at the same time.
An online model API made it easier to provide the necessary context reliably. Madklar places that access behind a controlled AI router handling model selection, usage limits, entitlements, retries and privacy-aware logging.
What production required
Madklar combines a React Native and TypeScript iPhone client with Cloudflare-based services and storage. Account access uses OAuth 2.0 authorization code flow with PKCE and OpenID Connect. The platform also handles subscriptions, monitoring, error recovery and erasure. Operational identifiers are pseudonymised before analytics storage in the EU.
Retailer feeds differ in naming, structure, coverage and quality, so each source has its own ingestion path into a shared ingredient and product model. Madklar compares product and price data from REMA 1000, Lidl, Bilka To Go, MENY, Wolt Market and nemlig.com.
The product is live on the App Store, supported by the mobile client, domain services, MCP connector, data pipelines and operational controls around it.
What this looks like in practice
A household asks for a weekly plan that works around attendance and uses food already in the pantry. Madklar retrieves the relevant state and gives it to the model as context. The application checks the proposal and the household approves it.
The approved plan becomes shared state. Shopping demand is calculated from recipes and inventory. Purchases and completed meals update the same state for the next interaction.
The pattern applies beyond meal planning. Operational AI products often need flexible language interaction alongside plans, inventory, procurement and mutable business state. A shared domain model, controlled tool access and explicit approval make that combination practical.
If you are moving an AI-enabled workflow from prototype to production, we would be glad to talk.
