Евгений Титов

Дмитрий, посмотрел на OmniHub немного с другой стороны. Я сам разработчик и строю сервис в области эффективного управления AI. Поэтому проблема платформенной зависимости мне очень знакома. В какой то момент довольно быстро приходишь к неприятному вопросу: что останется от моего продукта, если платформа под ним станет умнее? У OmniHub я вижу тот же вопрос с MAX. Квиз, квест, комментарии, сбор телефона под постом сейчас выглядят интересно. Но если MAX через полгода добавит половину этих механик нативно, сами механики перестанут быть защитой. Поэтому мне кажется, главный актив здесь нужно искать уровнем выше. Если вы строите сеть каналов, единый рекламный инвентарь, данные по эффективности механик, распределение рекламы, ОРД/ERID, расчёты с площадками и историю поведения пользователя между кампаниями, тогда MAX становится инфраструктурой. Можно заменить отдельную механику, добавить Telegram, подключить следующую платформу, а система останется. А если ценность держится прежде всего на возможности поставить квиз под постом в MAX, риск для покупателя действительно большой. Я бы поэтому при продаже за 10 млн показывал не столько prod и набор функций, сколько ответ на один вопрос: что именно покупатель приобретает такого, чего MAX не сможет просто добавить следующим релизом? Мне кажется, именно в ответе на него и находится настоящая стоимость OmniHub.

Никита, меня больше всего зацепил не AI-интервьюер, а фраза "вердикт по гипотезе". Мне кажется, здесь у продукта самое опасное место. Допустим, я привёл 20 человек. Но привёл их сам, значит выборка уже может быть кривой. Часть отвечала коротко, часть хотела быть вежливой. Где-то AI задал вопрос неудачно. Где-то человек неправильно понял формулировку. После этого сервис пишет: гипотеза подтверждена. Для неопытного фаундера такая зелёная плашка может оказаться опаснее отсутствия кастдева. Он наконец получил красивое разрешение делать то, что и так хотел делать. Я бы поэтому вообще убрал из продукта роль судьи. Не "гипотеза подтверждена", а: - нашли 7 повторяющихся сигналов; - 5 человек описали проблему на реальном прошлом опыте; - 4 платят за альтернативное решение; - 6 прямо противоречат основному выводу; - вот цитаты; - вот где данных пока недостаточно. И у каждого вывода должна быть дорожка назад до конкретного ответа респондента. Нажал на вывод, увидел, на каких репликах он построен. Тогда Cluer становится гораздо интереснее. Он не решает за фаундера, что правда, а быстро отделяет факты от красивых надежд. И вот за такой инструмент я бы уже платил. Потому что собрать ответы несложно. Сложно не обмануть себя, когда начинаешь их интерпретировать. ИМХО

Артем, мне кажется, самое интересное в Охвате начинается не где генерация и публикация в 16 каналов, а где вы обещаете связать отдельную единицу контента с заявкой и оплатой. Потому что увеличить охват на 300% само по себе несложно, если начать выпускать больше контента и размножать его по площадкам. Вопрос в другом: стал ли этот дополнительный охват приносить бизнесу больше денег. Я бы на вашем месте именно это сделал главным доказательством продукта. Не кейс в духе было 10 000 просмотров, стало 40 000. А конкретно: компания тратила на контент столько-то часов и рублей, получала столько-то квалифицированных лидов. Подключили Охват. Через два месяца расходы изменились так, количество контента так, CPL так, продажи так. Причем особенно интересно показать эффективность по отдельным каналам. Например, из десяти площадок семь дают красивые цифры, две дают лиды, а одна реально приносит продажи. Тогда система помогает не только производить контент, но и перестать тратить ресурсы туда, где он не работает. Вот такой кейс для меня был бы сильнее списка из пятидесяти функций. Потому что контента бизнесу сегодня и без того можно нагенерировать сколько угодно. Дефицит не в контенте. Дефицит в понимании, какой контент действительно окупается.

Вадим, посмотрел Клиенсу и обсуждение. Мне кажется, здесь проблема не столько в количестве конкурентов, сколько в формулировке продукта. Онлайн-запись, CRM, расписание, финансы, напоминания, лояльность уже воспринимаются как набор обязательных функций. Клиенту трудно выбрать новый сервис только потому, что в нем всё это тоже есть. Я бы попробовал продавать не CRM, а конкретный результат. Например: Клиенса для частного мастера, который ведет записи в мессенджере и теряет деньги на неявках. Или для небольшого салона, которому нужно вернуть больше клиентов на повторную запись. Тогда и продукт, и лендинг, и продвижение можно строить вокруг одной понятной цифры. Допустим: подключился за 15 минут, перенес клиентов, включил напоминания, через месяц получил на 20% меньше пропущенных визитов. Если продукт действительно способен это обеспечить, такая история сильнее списка из двадцати функций. Сейчас я бы проверял именно это: какой сегмент получает от Клиенсы самый заметный экономический эффект и за счет какой функции. Если такой ответ найдется, вопрос почему выбрать вас вместо Yclients или Dikidi станет намного проще. И не потому что дешевле или удобнее, нет, а просто потому что для конкретного бизнеса вы решаете конкретную проблему лучше.

Максим, у меня возник профессиональный вопрос. Я довольно глубоко занимаюсь архитектурой управления AI генерацией контента и вижу у такого подхода один серьезный потолок. Шаблон отлично решает задачу быстрого старта. Но одновременно он задает готовую траекторию генерации. Чем больше людей проходят через одни и те же конструкции, тем выше вероятность получить нормальный по форме, но усредненный контент. Для новичка этого часто достаточно. Для маркетолога, редактора или агентства уже нет. Профессиональная работа ведь начинается не с выбора шаблона поста. Нужно одновременно удержать аудиторию, задачу, фактуру, источники, ограничения бренда, структуру, стиль, SEO, требования площадки, запреты и еще следить, чтобы все эти требования не конфликтовали между собой. Поэтому мне действительно интересно, куда вы хотите двигать Neuroscribe дальше. В сторону еще большего количества готовых генераторов или в сторону системы, где специалист сможет собирать собственную логику управления генерацией? Потому что без такого слоя любой подобный сервис со временем рискует превратиться в очень удобный конвейер шаблонного нейрослопа. И установка внутрь все более сильных моделей эту проблему сама по себе уже не решает.

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

Данил, мне кажется, у WebRelay есть гораздо более крупная история, чем перенос сайтов с конструкторов. Самое интересное я увидел в вашем ответе про то, что сайт можно продолжать редактировать в бесплатной Tilda, а размещать уже на своем хостинге. По сути здесь рождается совсем другой продуктовый сценарий. Конструктор остается визуальным редактором, а WebRelay становится промежуточным слоем между ним и боевым сайтом. Если довести эту логику до автоматизации, пользователь вообще перестает выбирать между удобством конструктора и независимостью от него. Он меняет страницу привычным способом, WebRelay видит изменения, собирает новую версию, проверяет формы, ссылки, SEO, сохраняет предыдущий билд и публикует обновление на хостинг. Что-то сломалось, можно откатиться. Тогда вы продаете уже не разовый переезд за 490 рублей. Вы превращаете любой поддерживаемый конструктор в визуальную CMS, которая не владеет инфраструктурой сайта. А WebRelay фактически становится CI/CD слоем для no-code. Мне кажется, это одновременно решает главный вопрос из комментариев про дальнейшее редактирование и дает нормальную причину для подписки. Не рассматривали именно постоянную синхронизацию и публикацию как основной продукт, а сам перенос как первый вход в него?

Илья, мне кажется, в SashaSIP есть одна довольно сильная ветка развития, которой пока вообще не видно в позиционировании. Вы уже получили самое ценное сырье, сам разговор, причем запись остается локально на Mac. А дальше начинается гораздо более интересная история. Что если после завершения звонка приложение само разбирает разговор, вытаскивает договоренности, задачи, даты, имена, готовит краткое резюме, создает напоминание или событие в календаре? Причем обработка тоже может происходить локально. Я довольно глубоко занимаюсь темой управления AI и здесь как раз вижу редкую комбинацию. Не просто прикрутить нейросеть ради новой функции, а использовать ее там, где уже есть контекст, данные и конкретное действие пользователя. Тогда SashaSIP становится уже не звонилкой для Mac. Он начинает превращаться в личную рабочую память вокруг всех телефонных разговоров. Вы сами смотрели в эту сторону? Особенно интересно, насколько принципиально для вас сохранить именно local first подход.

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

Магомед, почитал обсуждение и мне кажется, что вы немного зря все время возвращаетесь к сравнению с облаками и WeTransfer. Сам занимаюсь разработкой технологического продукта и по своему опыту вижу, что иногда настоящий продукт появляется только тогда, когда перестаешь смотреть на исходную функцию. У вас уже есть лимит скачиваний, автоудаление, статистика, пароли, API. А если вообще перестать считать FastSend файлообменником? Файл можно рассматривать как отправление. Его передали конкретному получателю, зафиксировали получение, после этого доступ закрыли или уничтожили файл. Дальше сюда естественно ложатся подтверждение личности получателя, журнал передачи, одноразовый доступ, шифрование, уведомление о получении. Получается уже не место, куда загрузили файл, а цифровой курьер с контролем всей передачи. Не думали проверить именно такой сценарий? Мне кажется, здесь уже появляется причина использовать отдельный сервис, которой действительно нет у обычного облака.

Алексей, посмотрел сервис и мне кажется, что у продукта может быть более интересный потенциал, чем просто учет долгов. Сам занимаюсь разработкой сервиса в сфере управления AI и за время работы над продуктом несколько раз сталкивался с ситуацией, когда его реальная ценность обнаруживалась немного в другой точке, чем предполагалось изначально. У вас я вижу похожую историю. Сам долг ведь посчитать несложно. Намного сложнее все, что возникает вокруг него между людьми. Кто должен напомнить, когда это уместно, как не выглядеть мелочным, кто и что уже оплатил, одинаково ли обе стороны вообще понимают текущий баланс. То есть Depty потенциально может быть не столько учетом долгов, сколько нейтральным посредником между людьми в денежных вопросах. Вы сами не думали развивать продукт именно в эту сторону? Чтобы сервис брал на себя не только цифры и напоминания, но и весь неудобный протокол общения вокруг общих денег. Мне кажется, именно здесь может находиться гораздо более крупная ценность продукта. ИМХО.

Сергей, посмотрел MeetFlow уже глазами человека, который сам разрабатывает инструменты для эффективного управления нейросетями через J-сценарии и J-промпты. И здесь мне особенно интересна работа в реальном времени. Одно дело, когда AI ошибся в итоговом конспекте. Совсем другое, когда он дал неверную подсказку во время переговоров и уже повлиял на разговор. Отсюда главный вопрос: как у вас устроены сценарии? Это в основном специализированные промпты или уже система правил, приоритетов и ограничений? Еще интереснее длинный контекст. Если важная деталь прозвучала на пятой минуте, а значение приобрела на сороковой, как вы не даете ей потеряться при промежуточном анализе? И отдельная сложность, как мне кажется, ложные красные флаги. Если система слишком часто советует «на всякий случай», пользователь быстро перестает ее замечать. Иногда лучший совет AI вообще промолчать. Плюс интересно, насколько болезненно поддерживать расширение сразу под несколько платформ. Для пользователя это почти незаметная часть продукта, а для разработки, подозреваю, отдельный пласт работы. В целом направление нравится. Здесь AI не пытается заменить человека, а помогает ему лучше сделать свою работу. Но именно поэтому цена хорошей архитектуры управления моделью становится особенно высокой.

Максим, интересный кейс. Причем для меня особенно интересен именно ваш путь от контент-завода к отдельному SaaS. Я сам автор JaGGER SERVICE, платформы для профессиональной работы с AI-контентом, поэтому довольно глубоко залез в эту проблему с другой стороны. И у меня постепенно сформировалось довольно жесткое мнение: большинство контент-заводов обречены еще до запуска. Не в смысле бизнеса. Такая штука вполне может взлететь, собрать аудиторию и заработать деньги на хайпе, но... на мой взгляд, эта история не будет долгой. Почему? Потому что в случае с контент-заводами главна проблема внутри самого продукта производства. Я поясню. Контент-завод великолепно масштабирует производство. Но если нейросеть без серьезного управления производит пластиковый контент, то завод просто начинает производить пластик в промышленных объемах. Было 10 посредственных постов. Стало 10 000. Производительность выросла в тысячу раз. Ценность не выросла вообще. Это немного похоже на желтую прессу рядом с хорошим отраслевым изданием. Заголовки есть. Тексты есть. Картинки есть. Даже охваты могут быть. Но читать там особенно нечего. И это не теоретическая проблема. Я постоянно вижу обратную сторону рынка: требования к текстам, ТЗ, запросы компаний. Люди просят убрать нейрослоп, канцелярит, одинаковые конструкции, пустые выводы, выдуманные факты. Иногда доходят до простого запрета: "не использовать нейросети". Хотя проблема ведь не в самой нейросети. Это просто попытка защититься от характерного AI-пластика. Получить от модели хороший содержательный материал можно. Но она почему-то отдает его очень жадно. Нужны нормальная архитектура задачи, контекст, ограничения, управление, проверки и человек, который понимает, что он вообще хочет получить. А нейрослоп она отдает щедро. Сколько попросите. Поэтому идея "давайте уберем человека и масштабируем генерацию" у меня всегда вызывает вопрос: а что именно мы собираемся масштабировать? Зачем нам грядка из тысячи сорняков, если нужны десять нормальных помидоров? И вот здесь ваш кейс мне как раз нравится. На мой взгляд, Reels Boss в нынешнем виде уже не очень похож на тот самый контент-завод. Он не пытается придумать за человека, что ему сказать. Не пытается заменить автора. Есть исходное видео, созданное человеком. Есть его мысли, речь, содержание. А сервис берет на себя техническую работу: найти сильные фрагменты, нарезать, упаковать, подготовить форматы. То есть автоматизируется не смысл. Автоматизируется рутина вокруг смысла. И вот в такие AI-инструменты я верю гораздо больше. Человек делает то, где нужен человек. Машина забирает то, на что человеку жалко времени и рук. Поэтому я вполне могу представить, что сам воспользуюсь Reels Boss, когда появится такая задача. Здесь очень понятно, за что платишь и какую проблему сервис снимает. Возможно, самое ценное во всей вашей истории как раз в том, что большой контент-завод помог вам случайно обнаружить маленькую функцию, которая оказалась полезнее всего завода. Хороший поворот. Успехов проекту. Буду следить.

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

Алексей, попробовал посмотреть на Kaway не как на планировщик, а как на систему принятия решений. Допустим, я поставил сразу несколько целей. Развивать бизнес, больше заниматься семьей, учиться и восстановить нормальный режим. По отдельности AI легко построит хороший план для каждой. А что происходит, когда эти планы встречаются? В сутках все еще 24 часа. Одна цель начинает отнимать ресурсы у другой. Появляются ограничения, зависимости и выбор приоритетов. Как Kaway решает такие конфликты? Он просто собирает рекомендации в общий список или действительно пересчитывает маршрут целиком и понимает цену каждого нового решения? И еще интересен следующий шаг. Если через месяц выяснилось, что одна из исходных гипотез была ошибочной, система перестраивает связанные части маршрута или фактически строит новый план заново? Мне кажется, ценность здесь как раз может быть не в генерации планов. Их AI и так генерирует неплохо. Гораздо интереснее научиться управлять целостностью плана по мере того, как меняется реальная жизнь.

Дмитрий, мне здесь интересна не столько первая генерация продукта, сколько то, что происходит на десятой или двадцатой итерации. Сделать приложение по одному запросу уже умеют многие модели. Сложнее дальше управлять изменениями. Например, пользователь просит изменить авторизацию, потом логику оплаты, потом интерфейс. Как Вайбли понимает, какие части проекта можно менять, какие нельзя трогать и какие зависимости нужно проверить после каждого изменения? Есть ли внутри постоянная модель требований проекта, приоритетов, ограничений и связей между компонентами, или на каждой итерации агенты заново интерпретируют текущий контекст? И отдельно интересно, что происходит при конфликте требований. Например, новое пожелание пользователя ломает безопасность, бизнес логику или ранее согласованное поведение продукта. Система просто выполняет последнюю команду или умеет распознать конфликт и остановиться? Мне кажется, именно здесь проходит граница между генерацией кода и настоящим управлением разработкой через AI.

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

Никита, интересен вопрос именно к надежности результата. Чем больше нейросеть умеет восстанавливать структуру документа, таблицы, формулы и схемы, тем важнее понимать, где заканчивается распознавание и начинается ее интерпретация. Как Handium ведет себя, если часть документа невозможно уверенно прочитать? Например, модель видит структуру таблицы, понимает контекст строки, но конкретное значение распознано плохо. Есть ли жесткое правило ничего не достраивать по смыслу, даже если вариант кажется очевидным? И можно ли в готовом документе отличить то, что система действительно распознала, от того, в чем она сомневалась или что восстанавливала? Для меня в таких инструментах это критично. Ошибка OCR заметна. Правдоподобно восстановленная нейросетью ошибка гораздо опаснее, потому что человек может принять ее за исходный факт.

Макар, тема мне очень близка, поэтому возникло сразу несколько вопросов. Правильно ли я понимаю саму философию продукта: сначала мы получаем AI текст с определенными признаками машинной подачи, а потом отдельным пайплайном пытаемся эти признаки убрать? Мне здесь интересен другой подход. Почему не предотвращать их еще на этапе генерации? Например, заранее задать правила для синтаксиса, ритма, повторов, канцеляризмов, шаблонных связок, ложной экспертности, избыточных обобщений и других характерных паттернов. Тогда модель сразу генерирует более чистое сырье, а фильтр после генерации остается только контрольным слоем. Еще интересно, что именно является критерием хорошей переработки внутри Refrasa. Только снижение процента AI или есть независимый набор требований к самому тексту? Допустим, исходник специально содержит SEO вхождения, терминологию, факты, Tone of Voice, структуру и обязательные формулировки. Как система понимает, что именно разрешено переписывать, а что менять нельзя? И еще один момент. Если детектор считает человеческий текст машинным, а система начинает специально адаптировать его под этот детектор, не возникает ли ситуация, когда мы фактически оптимизируем текст под ошибку измерительного инструмента? Мне кажется, здесь очень интересная граница между очеловечиванием текста и полноценным управлением качеством AI контента.

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

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

Егор, интересный проект. У меня вопрос именно к архитектуре управления нейросетью. Я много работаю с AI в контент-маркетинге и вижу одну проблему: качество часто ломается не из-за слабой модели, а когда одновременно появляются десятки требований, источников и ограничений. Они начинают конфликтовать, а модель сама решает, чему верить и что считать главным. Как это решено в Pitchy? Например, исследование рынка говорит одно, данные пользователя — другое, CustDev-симуляция — третье. Есть ли над агентами единый технический слой, который определяет приоритеты, источники фактов, границы правил, работу при нехватке данных и проверку результата? Или это последовательная цепочка промптов с передачей контекста дальше? И отдельно интересно: различает ли система внутри результата факт, гипотезу и вывод модели? Мне кажется, именно здесь проходит граница между очередной надстройкой над LLM и самостоятельной методологией управления нейросетью.