Деньги в meal planning, restaurant discovery и food ordering есть: рынок подтверждён подписками около $5–10/месяц и B2B-тарифами от $149/месяц. Но standalone randomizer имеет низкую воспринимаемую ценность и много бесплатных заменителей.
ЗАХВАТ31
Базовая механика легко копируется. Есть локальная вьетнамская база блюд, бюджетный UX и privacy-first wedge, но нет сильного алгоритмического, data или distribution moat.
ДОСТУП6
Отсутствует лицензия, около двух контрибьюторов, нет релизов, production-часть закрыта, а права на сторонние ресурсы нужно проверять отдельно. Коммерческий reuse текущего кода юридически заблокирован.
«Коммерческий потенциал топит отсутствие лицензии и прав на reuse.»
Рыночный анализ · Обзор
Trưa Nay Ăn Gì — локально запускаемое веб-приложение, которое помогает выбрать, что съесть на обед, случайно предлагая блюдо с учётом фильтров и личного списка.
Проект превращает бытовой вопрос «что поесть сегодня?» в простую игровую механику: пользователь открывает «ящик», задаёт предпочтения или бюджет и получает случайное блюдо. Приложение работает локально без логина, backend и облака; предпочтения, списки блюд и история вращений сохраняются в cookie текущего браузера. Это скорее готовое consumer-приложение на React/Vite, чем библиотека с публичным API или SDK.
Какую боль решает
Снижает усталость от выбора еды и экономит время на принятии решения об обеде, особенно когда пользователь не хочет просматривать меню, спорить с коллегами или выбирать из длинного списка вариантов.
Сценарии использования
+Быстрый выбор обеда дома, в офисе или в университете.
+Выбор блюда в рамках заданного бюджета, например сценарий с бюджетом около 50k вьетнамских донгов на официальном сайте.
+Создание и использование персонального списка блюд с фильтрацией.
+Семейный или командный выбор еды, когда решение делегируется случайности.
+Приватное локальное использование без регистрации, backend, облака и синхронизации.
+Демонстрационный локальный React/Vite-проект для разработчиков.
Целевой пользователь
Жители Вьетнама и пользователи, знакомые с вьетнамской кухней; офисные сотрудники, студенты, семьи, небольшие команды; потенциально кафе, food courts, coworking-пространства и корпоративные столовые.
Подбирает рецепты от продуктов в холодильнике: ingredient matching, vibe-фильтры, scoring, история уже показанных рецептов и инструкции приготовления. Сильнее как recipe recommendation, но слабее в простоте, локальности и вьетнамской специализации.
Ищет ближайшие рестораны через Google Places API, показывает фотографии и отзывы, позволяет создавать списки ресторанов и выбирать случайный вариант. Сильнее как геолокационный restaurant discovery, но требует внешнего API и инфраструктуры.
CLI-приложение для случайного выбора домашнего блюда с weighted selection, пользовательскими предпочтениями и фильтром takeaway. Технически близко, но слабее в UX и consumer-подаче.
Позиционирование
Нишевая лидерская реализация по OSS-вниманию: по звёздам репозиторий заметно опережает найденные прямые OSS-аналоги, но функционально остаётся близок к meal randomizer без сильного технологического барьера.
Автоматически строит персональные планы питания по целям, бюджету, предпочтениям и расписанию, формирует shopping list.
Вендор заявляет 6 млн+ planners и 310 млн+ сгенерированных блюд; Google Play показывает 1 млн+ загрузок. Это vendor-reported/app-store floor, не аудированная активная база.
Заявлены 18 000+ рецептов и 800+ premium cooking classes. В пресс-релизе 2020 года компания заявляла о 2,5 млн приготовленных блюд — историческая, не текущая метрика.
AI-персонализация рецептов, 7-дневные планы, nutrition tracking, shopping lists, recipe communities и интеграция с экосистемой Samsung.
В 2022 году Whisk/Samsung Food сообщал о 500 000+ monthly active users; в период Whisk также заявлялись 500 млн+ взаимодействий с рецептами в месяц. Это исторические данные, не текущая MAU-оценка.
Привлечение клиентов, listing ресторана, онлайн-заказ, delivery, pickup и branded direct ordering.
Крупная marketplace-платформа; использованная страница цен не раскрывает конкретное число пользователей.
Marketplace Basic delivery15% комиссия
Marketplace Plus delivery25% комиссия
Marketplace Premier delivery30% комиссия
Pickup6% комиссия
Direct ordering Boost$99/месяц, 0% commission и отдельная обработка платежей
Direct ordering Pro$249/месяц, 0% commission и отдельная обработка платежей
Текущая монетизация проекта
Публично подтверждённой монетизации самого проекта нет: не обнаружены подписка, checkout, pricing, paid support, GitHub Sponsors или open-core. При этом проект не выглядит полностью заброшенным хобби: есть официальный production-сайт, README упоминает отдельный приватный frontend и API, репозиторий ведёт организация, опубликован npm-пакет. Вероятно, автор развивает связанный production-продукт, но модель дохода не доказана.
Коммерческий потенциал
ПОТЕНЦИАЛ · НИЗКИЙ
Заработать можно не на продаже randomizer как библиотеки, а на сервисе вокруг него: white-label lunch discovery, hosted cloud-версия, ресторанные каталоги, sponsored placement и комиссия за заказ. Текущий репозиторий нельзя безопасно монетизировать до устранения отсутствующей лицензии; после этого главным ограничением останутся слабый moat и отсутствие транзакционного слоя.
Спрос и рынок
Спрос на широкий слой meal planning, restaurant discovery и food ordering есть: в анализе приведены оценки meal planning market до $825.61 млн к 2030 году, restaurant guide apps около $941 млн в 2025 году с прогнозом до $1.369 млрд к 2032 году, а также намного более широкий meal-kit delivery market $39.4 млрд в 2025 году. Но адресуемый рынок именно для standalone lunch randomizer существенно меньше: пользователи могут заменить его Google Maps, delivery apps, LLM-чатом, заметками или простым random picker.
Ров / защищённость
Текущий ров слабый: вьетнамская локализация, локальный каталог, бюджетный сценарий, privacy-first и эмоциональный UX дают дифференциацию, но не защищают от копирования. Настоящий moat может появиться только вокруг качественной базы локальных блюд и заведений, актуальных цен и наличия, персональных данных выбора, интеграций с delivery-платформами и distribution через офисы, кафе, университеты и food communities.
Модели монетизации
+White-label для кафе, food courts, корпоративных столовых и кампусов
+Sponsored discovery и промо-блюда с прозрачной маркировкой
+Комиссия за заказ, pickup, delivery или бронирование после выбора блюда
+Hosted cloud-версия с аккаунтами, синхронизацией, историей, командными списками и admin-панелью
+Платная поддержка, self-hosting и кастомизация для локальных сетей заведений
+B2B analytics по популярности блюд и повторным выборам
Что нужно, чтобы сделать продукт
+Добавить лицензию на код и юридически очистить вклад контрибьюторов.
+Проверить права на изображения, звуки, шрифты, внешние данные, attribution и trademark.
+Вынести reusable decision engine из приложения в отдельный пакет с документацией и публичной схемой данных.
+Добавить backend, аккаунты, синхронизацию между устройствами, billing, admin-панель, analytics, monitoring и security policy.
+Подключить реальные ресторанные каталоги: геолокацию, часы работы, цены, наличие блюд, dietary/allergen metadata и профили заведений.
+Сделать интеграции с заказом, pickup, delivery или бронированием, чтобы рекомендация превращалась в транзакцию.
+Добавить retention-механики: историю, семейные и командные комнаты, recurring lunch, уведомления, повторный заказ и персональные рекомендации.
+Уйти от cookie-only storage, потому что данные не синхронизируются и слишком большие списки могут не сохраниться.
⚖ ЛИЦЕНЗИЯ · МОЖНО ЛИ КОММЕРЦИАЛИЗИРОВАТЬ
Лицензия отсутствует. Текущий репозиторий нельзя считать безопасно переиспользуемым OSS: коммерческое использование кода запрещено до отдельного разрешения, npm-публикация не заменяет лицензию, а fork на GitHub не даёт полноценного права на коммерческий derivative. Для разблокировки нужны LICENSE, подтверждение прав от владельца и существенных контрибьюторов, аудит ассетов и third-party notices; MIT/Apache-2.0/BSD были бы простым путём для коммерческого reuse, GPL/AGPL допустимы только с copyleft-ограничениями.
Риски и подводные камни
ВЫСОКИЙЛИЦЕНЗИЯ
SPDX-лицензия отсутствует. По default copyright laws публичность GitHub и возможность fork не дают права на коммерческое воспроизведение, распространение и производные работы. Нужно письменное разрешение владельца и существенных контрибьюторов либо добавление лицензии.
ВЫСОКИЙЮР. СЕРАЯ ЗОНА
README упоминает сторонние ресурсы, включая Valve/Steam-related assets, SimpleMaps и geoBoundaries. Attribution сам по себе не доказывает право на коммерческое использование.
ВЫСОКИЙМАЛЫЙ РЫНОК
605 звёзд и 440 звёзд за неделю подтверждают GitHub-внимание, но не доказывают реальных пользователей, retention, активные сессии, willingness to pay или конверсию в заказ.
ВЫСОКИЙКОНКУРЕНЦИЯ
Функциональность легко повторить, а крупные платформы уже имеют каталоги рецептов, reviews, геолокацию, доставку, grocery integrations, SEO, mobile distribution, платежи и рекламные каналы.
СРЕДНИЙСЛАБЫЙ РОВ
Без данных о реальных ресторанах, ценах, доступности и заказах продукт остаётся простым randomizer с низкой защищённостью.
СРЕДНИЙПРОЧЕЕ
Локальный cookie-only подход удобен для приватности, но плохо масштабируется: нет синхронизации, цены и меню могут устаревать, нет проверки доступности блюда и связи с заказом.
СРЕДНИЙЗАВИСИМОСТЬ ОТ АВТОРА
Около двух контрибьюторов, отсутствие релизов и очень молодой возраст репозитория создают зависимость от небольшой команды; community PR без contributor agreement могут усложнить контроль прав.
СРЕДНИЙПРОЧЕЕ
Если монетизация пойдёт через sponsored restaurants, нужно явно отделять честный случайный выбор от платного продвижения, иначе снизится доверие пользователей.
СРЕДНИЙКОНКУРЕНЦИЯ
Официальный сайт Mealime сообщает о закрытии сервиса 21 октября 2026 года при заявленных 4.5 млн пользователей, что указывает на сложности удержания и экономики meal-planning-продуктов.
+Коммерческие цены, масштабы и рыночные оценки структурированы из предоставленного разбора и не перепроверялись заново в этой задаче.
+Многие пользовательские метрики коммерческих аналогов являются vendor-reported, app-store floor или историческими данными, а не независимым аудитом активной базы.
+Прямые OSS-аналоги и их звёзды взяты из собранного разбора; полнота поиска по GitHub не подтверждалась повторно.
+Вывод о том, что production frontend/API частично приватные, основан на README и собранном разборе; содержимое приватной части не проверялось.
+Отсутствие публичной монетизации проекта основано на просмотренных публичных страницах в собранном разборе; скрытые договорённости, реклама, донаты или частные продажи могли не попасть в данные.
+Права на сторонние ресурсы, изображения, звуки, шрифты, данные, trademark и вклад каждого контрибьютора не были юридически проверены.
+Оценки demand/capture/access являются аналитическим суждением, а не измеренной финансовой моделью.
+Рыночные размеры meal planning, restaurant guide apps и meal-kit delivery относятся к более широким рынкам, а не к узкому standalone lunch randomizer.
+Сигнал GitHub-звёзд может отражать viral/discovery-интерес, но не доказывает retention, реальные сессии, MAU, конверсию в заказ или willingness to pay.
+Упоминание Mealime как сигнала сложности рынка основано на одном источнике из собранного разбора и не подтверждено ≥2 независимыми источниками.
truanayangi-com/truanayangi собрал 46 звёзд за окно, тогда как у автора всего 6 подписчиков — эффективная аудитория ≈ 139. Это даёт surprise-индекс 0.00859 (звёзды относительно охвата автора, а не в абсолюте). Удержание форков 72.7% и 3 внешних контрибьюторов отделяют реальный инструмент от разовой вспышки. Акселерация отрицательная — внимание остывает после пика.