Как я проверил идею ИИ‑продукта за один вечер до разработки: кейс «Ями»

Большинство цифровых продуктов умирают потому, что их авторы сначала пишут код, а потом ищут им рынок. Я в начале этого года едва не повторил эту схему — но один вечер за нейросетью и Google Таблицами развернул мой продукт в другую сторону и сэкономил минимум три месяца работы. Делюсь, что именно я проверял до старта разработки, что меня удивило и какие 7 шагов теперь делаю перед каждым новым запуском.

За последний год я запускал несколько собственных цифровых продуктов и заметил странную закономерность: те, что я делал сразу «потому что классная идея», получались никому не нужными. Те, которые я предварительно прогонял через короткий чеклист до разработки, выживали и приносили деньги.

Покажу всё это на примере одного из моих продуктов — телеграм‑бота «Ями — ИИ‑нутрициолог». Это бот, который определяет калорийность еды по фотографии. Идеальный кейс, чтобы показать пользу проверки идеи до разработки: без этой проверки я бы потратил три месяца на продукт, который не пережил бы первые две недели в проде.

Логика, которую я опишу ниже, работает не только для цифровых сервисов. Кофейня, бьюти‑услуга, маркетплейс‑карточка, обучающий курс — везде один и тот же принцип. Сначала проверки, потом деньги.

Проблема: как не повторить судьбу большинства подобных продуктов

Идея ко мне пришла бытовым способом. Я считал КБЖУ для своих тренировок и устал каждый раз вручную вбивать овсянку, банан и куриную грудку в калорийный трекер. Подумал, что было бы здорово фотографировать тарелку, а ИИ сам бы определял состав и калорийность.

Раньше я бы открыл редактор и начал кодить. Но опыт прошлых запусков научил: подождите.

Это, с одной стороны, было хорошей новостью: если рутина ручного ввода — главный отток, значит, мой бот её устраняет. С другой стороны — ниша оказалась плотно забита. Калькуляторы калорий делали все, кто только мог, от энтузиастов до Apple. Запустить ещё один такой же — гарантированный путь в архив.

Главный вопрос, который встал передо мной до разработки: где в этой нише брешь и как мне в неё попасть. Ответить на него по ощущениям и интуиции — это лотерея. Поэтому я сел проверять.

Задача: получить ответы за один вечер

Я выделил себе вечер и поставил конкретную задачу — за 4–6 часов получить трезвые ответы на 7 вопросов:

• могу ли я объяснить идею продукта незнакомому человеку за 30 секунд;
• сколько денег в принципе крутится в нише;
• кто конкретно будет за это платить и сколько;
• чем я отличаюсь от десятков существующих решений;
• как пользователь до меня доходит;
• сходится ли у меня юнит‑экономика;
• что должно быть в первой версии продукта.

Правило: если хотя бы на два‑три из этих вопросов внятного ответа не появится — идею откладываю в коробку, не теряя ни недели.

Решение: 7 проверок до старта разработки

Дальше — что я делал по шагам и к чему пришёл.

Сформулировал идею в одном абзаце. Это банально, но звонок реальности. Я записал: «Телеграм‑бот, который по фото еды определяет КБЖУ, считает дневную норму калорий и показывает остаток на сегодня. Для людей, которые хотят следить за питанием, но не хотят вручную вбивать каждый продукт».

Простая проверка: если этот абзац не складывается с первого раза — значит, я сам не до конца понимаю, что делаю. У меня сложился. Это уже плюс — переходим дальше.

Прикинул объём рынка. Тут я познакомился с тремя цифрами, которые помогают понять, есть ли вообще смысл заходить.

Первая — общий объём рынка в деньгах. Сколько в принципе денег в категории. Я попросил нейросеть посчитать рынок цифровых сервисов для здоровья, питания и ЗОЖ в России — получилось около 134 млрд рублей в год. Это про объём всей категории, в которой я как один из участников.

Вторая — доступный объём. Сужаю до своего конкретного сегмента: пользователи Telegram в России (50–55 млн активных), которые интересуются трекингом питания (10–15% аудитории), возраст 18–45 лет. Получаю около 3–4 млн человек, а это примерно 16,8 млрд рублей в год — то, до чего я в принципе могу дотянуться.

Третья — реально достижимый объём. Сколько можно заработать за 2–3 года. Для нового продукта 0,5–2% от доступного рынка — это нормальный реалистичный ориентир. Для «Ями» получилось 84–336 млн рублей годовой выручки.

Дальше я разобрал конкурентов и разделил их на три группы. Первая — крупные международные приложения для подсчёта калорий: огромные базы продуктов, но всё держится на ручном вводе, и это то самое слабое место, на котором люди отваливаются. Вторая — ИИ‑боты, обещающие «то же, что у меня»: я открыл несколько штук, и оказалось, что большинство просто перенаправляет фотографию в универсальную нейросеть и присылает сырой результат, без дневной нормы и трекинга. Третья — живые нутрициологи: дорого и медленно для массового пользователя.

То есть моя ниша — между ленивыми (нужно автоматическое распознавание) и серьёзными (нужны трекинг и норма, а не разовый ответ). Это и оказалось дверью в нишу.

Описал, кто конкретно будет платить. Самая неочевидная находка кейса случилась здесь. Я рисовал портрет типичного клиента: возраст, доход, привычки, мотивация. Сначала шёл по очевидной дороге — «человек, который хочет считать калории».

И в какой‑то момент поймал себя на ошибке. Я делаю продукт не для тех, кто хочет начать считать. Я делаю продукт для тех, кто УЖЕ пробовал — и сорвался. Это совсем другая аудитория. У них уже есть опыт боли (ручной ввод в прошлом приложении замучил), есть готовность платить (за избавление от рутины), и есть конкретный триггер срыва (момент, когда ручной ввод их добил).

Один из портретов получился такой: Елена, офисный работник, уже пробовала пару популярных трекеров калорий — хватило на 4 дня. Причина срыва: лень вручную разбирать сложные блюда вроде борща. Боится, что подсчёт превратится в невроз. Главная мотивация — экономия мозгового ресурса: не думать, не искать в базе, просто сфоткал и забыл. Готова платить 299 рублей в месяц — потому что «это меньше, чем чашка кофе».

Это полностью изменило, как я представляю себе клиента и где его искать. Не «начинающие ЗОЖники», а «уже сорвавшиеся бывшие пользователи трекеров». Совершенно разные каналы привлечения, совершенно разные тексты в рекламе.

Сформулировал оффер. После рынка и аудитории оффер собрался почти сам. Но я перебрал штук семь вариантов, прежде чем остановиться на финальном.

Слабые версии звучали так: «Удобный бот для подсчёта калорий», «ИИ‑нутрициолог в кармане», «Считай калории легко». Все они отвечали на «что это», но не отвечали на главный вопрос — «почему я».

Сильная финальная формулировка: «Подсчёт калорий по фотографии за 3 секунды вместо 5 минут ручного ввода». Здесь сразу три вещи: что это (подсчёт калорий), как работает (по фото), почему это лучше конкурентов (3 секунды против 5 минут).

Урок, который я вынес: оффер не пишется «из головы». Он собирается из двух предыдущих шагов. Если знаешь слабое место конкурентов и знаешь больную точку клиента — оффер складывается за полчаса.

Нарисовал воронку, как клиент попадает в продукт. На бумаге, без всяких сервисов. Откуда узнал → куда зашёл → что сделал первый раз → что вернёт его обратно.

Получилось так: посевы в телеграм‑каналах про ЗОЖ → переход в бот → первая фотография за 3 секунды → дневная норма с напоминаниями.

Тут была вторая важная находка. Я планировал гнать трафик через рекламу во внешней соцсети с фото. Но когда нарисовал реальный путь — стало ясно, что моя соцсеть это сам Telegram. Если человек уже сидит в Telegram и ищет решение боли, ему странно куда‑то ходить из соцсети, чтобы потом вернуться в Telegram же. Бюджет на внешнюю рекламу я в финмодель не заложил.

Собрал базовую финмодель. Без этого пункта я бы попался.

Дальше — пожизненная ценность клиента, то есть сколько он мне принесёт за всё время. При подписке 299 рублей в месяц и среднем сроке удержания 3–4 месяца — это 900–1200 рублей.

И тут получилось интересно. При плохом сценарии (низкая конверсия, дорогое привлечение) экономика не сходится. При среднем — еле‑еле. Чтобы экономика работала уверенно, мне нужно было либо удержание клиента длиннее (значит, нужна механика возврата — например, дневные напоминания), либо средний чек выше (значит, годовая подписка со скидкой), либо канал привлечения дешевле.

До этой проверки я планировал стоимость 99 рублей в месяц — «для массовости». После проверки понял: при таком ценнике мне нужна гигантская воронка, и я её не потяну. Поэтому в MVP пошёл с 299 рублями плюс годовой подпиской по 1990 рублей.

Спроектировал MVP, который реально могу запустить. MVP — это минимально работоспособная версия продукта, на которой можно проверить главную гипотезу. Здесь я отрезал примерно две трети того, что хотел сделать.

Первоначальный план разработки выглядел так: онбординг из 10 вопросов (рост, вес, цели, активность, ограничения по продуктам и так далее), фотораспознавание, дневник питания, рецепты под цели, интеграция с Apple Health, рекомендации по тренировкам. На это разработка ушла бы три месяца минимум.

После всех проверок я переписал план MVP за 20 минут. Осталось три вещи: онбординг из 3 вопросов (вес, цель, активность), фото еды с распознаванием, дневная сводка с остатком калорий. Всё. Никаких рецептов, никаких интеграций, никакой соцактивности.

Логика была простая: я не знаю, поедет ли этот продукт в принципе. Поэтому я делаю минимум, на котором можно проверить главный вопрос — будут ли люди платить за устранение рутины ручного ввода. Если поедет — допилю остальное по запросам реальных пользователей, а не по своим фантазиям. Если не поедет — потерял три недели на разработку, а не три месяца.

Результат: что я получил после 4 часов аналитики

Когда вечер закончился, у меня был не только проверенный план — у меня был совершенно другой продукт.

Вот что изменилось по сравнению с тем, что я держал в голове до проверки:

• онбординг сократился с 10 вопросов до 3;
• функционал MVP сократился с 6 крупных фич до одной плюс минимальной обвязки;
• цена выросла с 99 до 299 рублей в месяц;
• портрет клиента сместился с «начинающего ЗОЖника» на «бывшего пользователя трекеров»;
• основной канал привлечения сместился с внешних соцсетей на посевы в Telegram.

Иначе говоря, если бы я начал кодить сразу — я бы делал не тот продукт, не для тех людей, по неправильной цене, через неправильные каналы. И каждое из этих несоответствий по отдельности убило бы запуск.

Бот сейчас находится на стадии доработок — корректирую механики удержания и точность распознавания фото. Главный итог этого кейса для меня — даже не цифры выручки. Главный итог — у меня появился рабочий метод проверки идей до разработки. Я применил его ещё к нескольким своим проектам, и каждый раз цикл проверки занимает один вечер. Иногда результат — «идея отличная, запускаем». Иногда — «рынок маленький, конкуренты сильные, не стоит». Второй ответ ценнее: он экономит месяцы.

Главный вывод: 4 часа проверки до старта разработки экономят 2–3 месяца работы впустую. Не пропускайте этот этап

Что я понял после этого опыта

Несколько уроков, которые забрал из кейса и применяю теперь к каждому новому продукту.

Любая идея сильно переоценена в голове автора. Цифры из реального анализа всегда корректируют картину. Часто в сторону «ниша интереснее, чем я думал». Иногда — «лучше не лезть».

Аналитика до разработки — это не бюрократия и не теория. Это прямая экономия денег и времени. Один вечер с Google Таблицами и нейросетью стоит трёх месяцев разработки впустую.

Половина «крутых функций» отсеивается после анализа аудитории. И продукт от этого становится лучше, а не хуже. Меньше функций — яснее ценность.

Трезвые «нет» так же полезны, как трезвые «да». Если проверки показали, что в нише делать нечего — это сэкономленные месяцы, а не потраченное зря время.

А вы прогоняете идею через какой‑то чеклист до разработки или вкладываетесь в первую партию? Что бы вы добавили к моим 7 проверкам из своего опыта? Поделитесь в комментариях — соберём общими усилиями расширенную версию.