Real prices, refreshed every morning
Four Barcelona chains get scraped nightly, around 12,700 products, with full price history, promo flags and stock status. When a price moves we keep both numbers.
In development · Barcelona first
Tell BudgetFork your budget, how many days, and what's already in the fridge. You get back a meal plan, a shopping list split by supermarket, and a total built from the prices those shops are charging today.
The gap
They'll hand you a beautiful week of food and no idea whether it costs €40 or €140. Meanwhile the same chicken breast can differ by 60% between two shops four streets apart, and half of what you need is already sitting in your fridge.
BudgetFork starts from the other end, with the money. It reads the shelf, it counts your pantry, and it does the arithmetic in code, so the number on screen is the number you pay at the till.
Budget was €50 · 9 meals · €3.49 per serving
How it works
“I've got €50 for three days, just me, breakfast and a late lunch. I like chicken and pasta. There's eggs, cheese and ham in the fridge.” There are no forms to fill in and nothing to configure first.
Every ingredient gets matched to a real product on a real shelf at each supermarket, then priced from data scraped that morning. Anything already in your kitchen drops to zero.
Meals for each day, the list grouped by shop, and what every serving cost you. If day two looks wrong, say so and it plans again inside the same budget.
The conversation
BudgetFork holds a real conversation. It can ask you something, let you ask something back, take a detour into “hang on, what's olive oil going for?”, then pick the plan up where it left off.
The model reads your sentence and writes the reply. Everything in between, the matching and the pricing and the sums, runs as ordinary code.
Under the hood
Four Barcelona chains get scraped nightly, around 12,700 products, with full price history, promo flags and stock status. When a price moves we keep both numbers.
The language model reads your request and writes the reply around the result. Matching, pricing, pantry discounts and the budget arithmetic all happen in plain Go, where they can be tested.
Ask in English, French or German. Ingredients resolve across languages into Spanish shelf products through a multilingual embedding index.
Give it a postal code or just “Gràcia”. Regional stock zones are filtered to what's genuinely available near you.
Pantry items match at ingredient level, so “ham” never quietly covers chorizo. They come off at the end, which keeps the plan honest about what you still have to buy.
Every ingredient is priced at every shop that stocks it, and the total comes back broken down per store, so you can judge whether the second stop is worth the walk. A promoted product is labelled as one and never removes a cheaper option from the comparison.
Postgres with pgvector, a Go API, and an LLM endpoint that points at a hosted provider or at Ollama on the same machine. Development runs entirely local; production uses whichever backend answers fastest.
Coverage
Adding a store means writing one scraper and setting a language and a currency. The planner, the matching and the budgeting logic stay exactly as they are when the city changes. Madrid, Lisbon, Berlin and Belgrade are next in line.
Want your city or chain first? Say so when you sign up.
Questions
Not publicly. The scrapers, the price database, the matching pipeline and the planning API all work today. What's left is the front end and somewhere to host it. People on the waitlist get keys first.
They're the shelf prices each chain publishes, re-scraped daily, with the full history kept. Where a store prices by region we hold every zone separately and filter down to your area. Nothing gets averaged.
The total never passes through the model. The language model reads your request and writes the sentence around the answer. The plan itself, meaning which product from which shop in what quantity, gets computed in Go and checked against the database.
Vegetarian, vegan, gluten-free and allergen exclusions are proper inputs rather than a filter bolted on at the end. Telling it what you like also pulls the plan toward food you'll actually eat instead of the cheapest available calories.
No. Nothing that identifies you leaves the system. What a supermarket can buy is demand data pooled across everyone using BudgetFork, meaning what people are planning to cook and how a basket shifts when a price moves. Your individual list is not in it.
The supermarkets, in three ways: that aggregate demand data, a fee when a plan sends a basket their way, and promoted products, where a brand can be put forward as an option for a recipe.
That last one has a hard limit worth stating plainly. A promotion can suggest a product. It can never hide a cheaper one, and it never removes a shop from the price comparison. You always see what everything costs everywhere, and anything promoted says so.
There already is one. Chat, price queries, recipe search and streaming budget plans, with API keys and rate limiting. It opens up alongside the app.
Early access opens in Barcelona first. Leave an email and you'll get one message when it's ready.
Or just write to us at eat@budgetfork.com