Web AppShut Down

Botnim

Botnim は、nearby dishes と nutritional values を map する food-discovery web app and chatbot でした。

元のストーリーを見る

プロダクト概要

何だったか

Botnim は、Messenger chatbot から始まり later map に移り、users が nutritional values と location で nearby dishes を見つけられるようにしました。

誰のためか

diners with nutrition preferencesrestaurantsbusiness owners wanting menu visibility

課題 / 価値

restaurant dishes を nutrition と food preferences で searchable にすること。

中核ワークフロー

  • nearby dishes を見つける
  • nutritional values で dishes を filter する
  • food preferences で filter する
  • verified dish nutrition を表示する

プロダクト形態

Messenger chatbotweb applicationdish mapnutrition data service

価格モデル

restaurants は lab checks と visibility に支払う可能性があり、lab commission ideas もありました。exact revenue totals は disclosed されていません。

競合または代替手段

restaurant discovery appsmenu websitesnutrition databasesGoogle Mapsfood delivery apps

何が起きたか

概要

Botnim は chatbot から map に移りましたが、costly lab-verified dish data と diner-restaurant-lab の難しい coordination loop に依存していました。

結果

Botnim は、founders が data collection と market loop が機能していないと結論づけた後、bad-market-fit startup として shut down しました。

中核リスク

data-rich consumer product は、repeat paid loop が証明される前に costly verified data と multi-sided adoption を必要としました。

終了理由

founders は wrong market direction、外食時に diners が十分 nutrition を気にしないこと、costly lab-check dependencies、restaurants が users before paying を求めることを挙げました。

需要シグナル

founders は slow Messenger bot から map に移った後に interest を見つけましたが、core business には costly verified dish data が必要でした。restaurants は users がいる前に checks へ支払いたがらず、users は十分な restaurants を必要とし、lab trips は time と cost を増やしました。

集客上の問題

model は diners、restaurants、laboratory の three sides が同時に動くことに依存しました。door-to-door restaurant sales は interest を作りましたが、各 front が他の progress に依存し、momentum は compound しにくくなりました。

タイムライン

  • idea は Tel Aviv の nutrition と eating-out habits から生まれました
  • Messenger chatbot を first built しました
  • chatbot は real-time food search には slow すぎると分かりました
  • dish filters 付きの map interface を launched しました
  • restaurant outreach と lab checks が続きました
  • market-fit と dependency problems の後に project は stopped しました

作る前に確認すること

なぜ重要か

useful record ごとに manual verification、lab work、vendor coordination、field sales が必要なら、interface は core risk ではありません。unit economics と repeat buyer が core risk です。

主な確認事項

nutrition data を軸に map や chatbot を作る前に、verified-data cost、restaurant payment、diner demand を証明してください。

チェックリスト

  • ten records を manually verify し true cost を計算する
  • subsidizing 前に restaurants に full cost を pay してもらう
  • diners が data を interesting と言うだけでなく meals を選ぶか測る
  • one verified record は money と time でいくらかかるか
  • data collection に誰が支払い、どれくらい repeat するか
  • user demand は suppliers が pay する enough value を作るか
  • coverage を広げる前に one small area で product は機能するか

参考になる場合

  • verified data を軸に product を作っている
  • users が value を得る前に restaurants、labs、vendors、creators など suppliers が必要である
  • marketplace を始めるために data collection を subsidizing している

参考になりにくい場合

  • data が cheap、self-serve、already available である
  • each verified record を賄える repeat buyers がいる

開発前テスト

  • small set of dishes で one neighborhood を run する
  • broad map を build する前に restaurant participation を sell する
  • app を build する前に spreadsheet または simple landing page で user searches を test する

応用できる学び

  • full interface の前に one verified-data unit を validate する
  • buyer lifetime value を知らずに core data を subsidize しない
  • one side が clearly pays するまで three-sided business models を避ける
  • target user の real behavior が stated preference と合うか確認する

今作るなら

one neighborhood と tiny set of restaurants から始めてください。diners が verified nutrition data で meals を選ぶか、restaurants が lab checks と sales work を賄う enough amount を repeat paying するかを manually test してください。