Botnim
Botnim was a food-discovery web app and chatbot that mapped nearby dishes with nutritional values.
View original storyProduct snapshot
What it was
Botnim helped users find nearby dishes by nutritional values and location, first through a Messenger chatbot and later through a map.
Who it was for
Problem / value
Make restaurant dishes searchable by nutrition and food preferences.
Core workflow
- find nearby dishes
- filter dishes by nutritional values
- filter by food preferences
- show verified dish nutrition
Product form
Pricing model
Restaurants could pay for lab checks and visibility, with possible lab commission ideas; exact revenue totals are not disclosed.
Competitors or alternatives
What happened
Summary
Botnim moved from chatbot to map, but the product depended on costly lab-verified dish data and a difficult diner-restaurant-lab coordination loop.
Outcome
Botnim shut down as a bad-market-fit startup after the founders concluded the data collection and market loop were not working.
Core risk
A data-rich consumer product required costly verified data and multi-sided adoption before a repeat paid loop was proven.
Shutdown reason
The founders cited wrong market direction, diners not caring enough when eating out, costly lab-check dependencies, and restaurants wanting users before paying.
Demand signal
The founders found interest after moving from a slow Messenger bot to a map, but the core business needed costly verified dish data. Restaurants wanted users before paying for checks, users needed enough restaurants to care, and lab trips added time and cost.
Distribution issue
The model depended on three sides moving together: diners, restaurants, and the laboratory. Door-to-door restaurant sales created interest, but each front depended on progress from the others, which made momentum hard to compound.
Timeline
- idea came from nutrition and eating-out habits in Tel Aviv
- Messenger chatbot built first
- chatbot proved too slow for real-time food search
- map interface launched with dish filters
- restaurant outreach and lab checks followed
- project stopped after market-fit and dependency problems
Before you build
Why it matters
If every useful record requires manual verification, lab work, vendor coordination, or field sales, the interface is not the core risk. The unit economics and repeat buyer are.
Primary check
Prove the verified-data cost, restaurant payment, and diner demand before building a map or chatbot around nutrition data.
Checklist
- Manually verify ten records and calculate true cost.
- Ask restaurants to pay full cost before subsidizing.
- Measure whether diners choose meals using the data, not just say it is interesting.
- What does one verified record cost in money and time?
- Who pays for data collection, and how often do they repeat?
- Does user demand create enough value for suppliers to pay?
- Can the product work in one small area before scaling coverage?
Relevant if
- You are building a product around verified data.
- Your app needs restaurants, labs, vendors, creators, or other suppliers before users get value.
- You are subsidizing data collection to start the marketplace.
Less relevant if
- Your data is cheap, self-serve, and already available.
- You have repeat buyers who pay enough to cover each verified record.
Pre-build tests
- Run one neighborhood with a small set of dishes.
- Sell restaurant participation before building a broad map.
- Test user searches with a spreadsheet or simple landing page before building the app.
Transferable lessons
- Validate one verified-data unit before building the full interface.
- Do not subsidize core data without knowing buyer lifetime value.
- Avoid three-sided business models until one side clearly pays.
- Check whether the target user’s real behavior matches the stated preference.
If you build this today
Start with one neighborhood and a tiny set of restaurants. Manually test whether diners use verified nutrition data to choose meals and whether restaurants repeatedly pay enough to cover lab checks and sales work.