Почему миру не нужен ещё один счётчик калорий: как я выбросил B2C-концепцию и ушёл делать SaaS для нутрициологов

Я программист и привык смотреть на проблемы довольно прямолинейно: есть данные — надо их правильно собрать, обработать и удобно показать пользователю.

Я понял, что технически могу построить именно тот продукт, который задумал.

Проблема только в том, что миру совершенно не обязательно нужен ещё один такой продукт.

Это может быть сигналом, что ты пришёл слишком поздно. Посмотрите на рынок трекеров питания. Есть продукты с огромными базами еды, штрихкодами, рецептами, интеграциями, десятилетней историей и миллионами пользователей.

Допустим, я сделаю интерфейс немного красивее. Распознавание еды немного умнее. Добавлю ещё десять графиков. Что принципиально изменится для пользователя? Скорее всего, ничего.

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

Возьмём человека, который работает с нутрициологом, тренером или wellness-консультантом. Еда может быть записана в одном приложении. Вес — в приложении весов. Шаги, пульс, тренировки и сон — в Apple Health, Health Connect или сервисе производителя часов.

Результаты лабораторных анализов лежат PDF-файлами. Добавки — в заметках. Фотографии еды — в Telegram или WhatsApp. Предыдущие рекомендации специалиста — ещё где-нибудь. А часть информации вообще существует исключительно в памяти клиента и специалиста.

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

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

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

То же самое касается веса. «68 кг» почти ничего не говорит. А график за шесть месяцев вместе с изменением питания и активности уже рассказывает историю.

И здесь я пришёл к достаточно простому выводу:

ценность health-продукта может быть не в том, сколько разных данных он умеет хранить, а в том, насколько хорошо он связывает их во времени.

После этого архитектура проекта начала меняться.

Наверное, это был более важный поворот. Когда делаешь приложение про здоровье, автоматически думаешь: Пользователь — человек, который следит за собой. Это очевидная B2C-модель.

Но попробуем посмотреть на человека, который профессионально ведёт 20, 30 или 50 клиентов. У каждого клиента своя история. Кто-то прислал новые анализы. Кто-то две недели не измеряет вес. Кто-то изменил рацион. У кого-то изменилась физическая активность. Кто-то принимает добавки. С кем-то специалист обсуждал цель месяц назад и теперь должен вспомнить контекст разговора.

И всё это довольно часто обслуживается комбинацией: мессенджер + Google Sheets + заметки + PDF + память специалиста.

И я поймал себя на мысли: может быть, клиентское приложение — вообще не весь продукт? Может быть, гораздо интереснее строить рабочее пространство для человека, который ведёт множество таких клиентов? Это уже совсем другая задача.

Это интересный продуктовый парадокс.

Возьмём:

Если поставить в центр обычного пользователя, получится wellness-трекер. Если поставить в центр специалиста, который ведёт 50 клиентов, те же самые данные превращаются уже почти в профессиональную систему.

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

Именно в этот момент я понял вещь, которая сейчас кажется очевидной: категорию продукта определяет не набор функций. Её определяет рабочий процесс, в который эти функции встроены.

Это был следующий вопрос, который я задал самому себе. Потому что практически всё описанное выше можно хранить в Notion или Google Sheets, и это правда. Более того, если специалист ведёт пять клиентов, отдельная система ему, возможно, вообще не нужна.

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

То есть пользователь фактически самостоятельно программирует себе специализированный SaaS — только без программиста. Мне кажется, это вообще хороший способ искать идеи для B2B-продуктов:

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

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

И здесь возник ещё один соблазн.

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

Мне такой путь не нравится. Во-первых, это довольно опасное обещание. Во-вторых, я думаю, что мы сильно переоцениваем необходимость создавать ещё одного AI-ассистента внутри каждого приложения.

Меня гораздо больше заинтересовала другая идея. А что если AI будет не продуктом, а интерфейсом к продукту?

Вместо того чтобы искать нужный график:

Специалист вместо фильтрации списков просит: «Покажи клиентов, у которых давно не обновлялись измерения».

То есть модель не должна обязательно владеть данными или делать медицинские выводы. Она может просто помогать человеку разговаривать со своими данными на естественном языке. Эту архитектуру я сейчас исследую отдельно, в том числе через MCP (протокол, позволяющий AI-системам работать с внешними инструментами), но это уже тема для отдельной статьи.

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

А сначала спросить:

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

Сейчас мне интереснее всего посмотреть, насколько эта гипотеза соответствует реальности

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

Как на самом деле выглядит ваше рабочее место?

А здесь я хочу дальше писать не только о самом продукте.Мне гораздо интереснее разбирать процесс его создания: как разработчик учится проверять продуктовые гипотезы, где AI действительно оказывается полезен, почему некоторые технически красивые решения никому не нужны и что происходит, когда пытаешься строить один SaaS сразу для разных стран и рынков.

Если эксперимент получится — будет интересно посмотреть, почему. Если нет — думаю, разбор ошибок окажется ещё интереснее.