Как я строю AI-продукты соло: разработка Cruxly и Planio

Почему два продукта, а не один

У меня нет сооснователя, нет инвестора и нет отдела, который что-то решает, пока я сплю. Есть я, ноутбук и два продукта, которые я строю параллельно: Cruxly, AI-инструмент для конспектирования видео, PDF и документов, и Planio, сервис для мастеров и сервисных компаний, которые работают с заявками на выезд. Со стороны параллельная разработка двух непохожих продуктов похожа на распыление внимания. На деле это осознанное решение с разным критерием для каждого продукта. Часть решений уже провалилась, прежде чем заработать.

Я не даю здесь советов вида "как тебе тоже запустить продукт соло". У меня нет миллионных выходов и нет права поучать. Есть конкретный опыт двух запусков разного типа продукта в разное время. То, что я из этого вынес, может пригодиться, если ты сейчас решаешь ту же задачу: строить одну вещь глубоко или несколько параллельно и рисковать не довести ни одну до конца.

Оба продукта на момент публикации ещё в процессе. Итоги подводить рано. Часть решений, которые я здесь описываю, ещё не проверена временем и вполне может оказаться ошибкой, которую я разгляжу только через год. Я предпочитаю написать это сейчас, пока решения свежие, а не переписывать историю задним числом под уже известный результат.

Как появился Cruxly

Идея Cruxly выросла из раздражения, а не из рыночного исследования. Я готовился к докладу на митапе разработчиков и обнаружил, что трачу на пересказ уже увиденного и прочитанного больше времени, чем на само содержание. Часовое видео превращалось в конспект на полчаса ручной работы: пересматривать, останавливать, записывать тезисы.

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

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

Рынок AI-конспектирования видео и документов не пустой, и я не делаю вид, что это не так. Крупные зарубежные аналоги при этом пользователям в России сейчас практически недоступны, и это тоже часть картины, а не только фиче-сет.

Я начинал с сценария под разовый быстрый вопрос: одна ссылка, один запрос, результат за минуту, без завода проекта под многодневную исследовательскую сессию — на нём и вырос костяк первых пользователей. Но сегодня главная фича Cruxly — не быстрый разовый разбор, а собственный AI-блокнот: добавляешь несколько источников — видео, PDF, веб-страницу — и ведёшь по ним общий чат. Быстрый вход без блокнота никуда не делся, просто это уже не центр продукта, а более лёгкий путь рядом с ним. Это и есть Cruxly.

Как появился Planio

Planio — полная противоположность Cruxly по происхождению. Я не сталкивался с этой проблемой лично: я не сантехник и не электрик. Идея появилась из наблюдения за рынком инструментов для сервисного бизнеса на выезде в России и СНГ: фрагментированным, без одного доминирующего игрока, с несколькими игроками среднего размера, каждый из которых закрывает часть задачи, но не всю.

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

Мастер на выезде решает одну и ту же задачу каждый день: принять заявку, оценить стоимость, построить маршрут, зафиксировать статус работы, выставить документ клиенту. Planio закрывает это одним приложением: онлайн-запись 24/7, календарь с маршрутом на карте, статусы заявок, база клиентов, смета, которую клиент подписывает пальцем в своём кабинете, каталог материалов и закупки, документы за пару кликов, доходы по периодам.

Я честно посмотрел на существующих игроков рынка. У каждого нашёлся перекос: где-то сложная настройка, которая отпугивает мастера без технической подготовки, где-то интерфейс, спроектированный явно под бригаду, а не под одного человека с телефоном в кармане. Здесь и лежит развилка, которая определила Planio сильнее любого отдельного экрана интерфейса. Можно было сделать инструмент только для мастера-одиночки и упереться в потолок в день, когда у него появится первый нанятый помощник. Я спроектировал Planio иначе: он одинаково закрывает задачу и для одного человека, и для владельца бригады из десяти мастеров, а тарифы отличаются по числу сотрудников, а не по набору функций. Когда бизнес мастера вырастет, ему не придётся переезжать на другой сервис — просто добавить команду в тот же аккаунт.

Решение строить именно это, а не второй AI-инструмент, было стратегическим. Я не хотел, чтобы весь портфель зависел от одной категории продуктов, которую может подорвать одно обновление модели от OpenAI или Google. Field-service CRM — скучная категория с точки зрения хайпа и устойчивая с точки зрения спроса: сервисному бизнесу нужно принимать заявки независимо от того, что происходит с LLM в этом квартале. Я видел, как несколько знакомых соло-разработчиков строили весь бизнес вокруг тонкой обёртки над чужим API, а потом смотрели, как продукт становится не нужен после одного релиза от самого провайдера модели. Мне не хотелось повторять эту ошибку во второй раз.

С технической стороны Planio устроен проще, чем Cruxly — здесь нет зависимости от качества генерации языковой модели, а значит нет риска, что продукт внезапно станет хуже из-за изменения в чужом API. Основная сложность лежит в деталях: правильно посчитанный маршрут с учётом реальных пробок, корректно сгенерированный документ под требования конкретного вида работ, интерфейс, который не путает мастера, открывающего приложение на бегу между двумя заявками.

Соло против команды: что я потерял и что выиграл

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

Конкретный пример: с сооснователем решение по цене Pro-тарифа Cruxly свелось бы к одному разговору на час — обсудили, сверили интуицию, приняли решение. В одиночку сверить интуицию не с кем, и вместо разговора пришлось самому собирать основания: сравнивать похожие продукты, читать форумы, проверять гипотезы на реальных данных.

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

Соло-разработка держится на компромиссе с ценой в обе стороны, и я не считаю её универсально правильным выбором. Для Cruxly и Planio на текущем этапе она работает: оба продукта достаточно маленькие, чтобы один человек физически успевал вести и код, и продукт, и минимальную поддержку. Если любой из них вырастет настолько, что я перестану успевать, баланс придётся пересматривать, и я предпочитаю признать это заранее.

Ценообразование и позиционирование в двух разных нишах

Cruxly и Planio конкурируют в нишах с принципиально разной структурой, и это напрямую определяет, как я их продаю.

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

Ценообразование Cruxly устроено в три ступени, и это прямой ответ на тот же вопрос "зачем платить, если есть бесплатное". Гостевой доступ без регистрации закрывает разовое любопытство: один анализ в день, видео до часа. Бесплатный аккаунт снимает часть лимитов и даёт попробовать второй мозг на объёме, которого хватает, чтобы почувствовать разницу. Платный Pro-тариф начинается там, где человек понял, что пользуется продуктом регулярно и платит за объём и память, а не за сам факт доступа к генерации. Это компромисс, не идеальное решение: ответ на вопрос "зачем платить, если есть бесплатное" пришлось вписать в бесплатный тариф, а не в текст рядом с ценой.

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

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

Разница в подходе к этим двум продуктам показывает то, что я не сразу понял на старте: универсальной формулы ценообразования для "AI-продукта соло-разработчика" не существует. Формула зависит от структуры конкретной ниши, а не от того, что продукт сделан одним человеком. Есть и деталь, которую я упустил у обоих продуктов: цена психологически считывается не только как цифра, но и как сигнал о серьёзности продукта. Слишком низкая цена у Planio читалась бы частью владельцев как "значит, там мало функций". У Cruxly обратная ситуация: аудитория, привыкшая к бесплатным аналогам, ждёт объяснения, зачем вообще платить. Оба случая решаются одинаково: контекстом рядом с ценой.

Первые пользователи без бюджета на маркетинг

У меня никогда не было рекламного бюджета ни на один из двух продуктов, и я не планирую его заводить в обозримом будущем. В моём случае реально работает одна модель: трафик из блога. Каждый пост здесь пишется как самостоятельный, полезный текст под конкретный информационный запрос, и только внутри него, там, где это органично, стоит контекстная ссылка на Cruxly или Planio — не баннер и не призыв "попробуй бесплатно" в шапке.

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

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

Первых 50 пользователей Cruxly мне принесли именно несколько постов о рабочих процессах с AI, не продакт-хант и не таргетированная реклама: ссылка на инструмент оказалась логичным следующим шагом для человека, который уже читал про конспектирование источников и как раз искал что-то для этой задачи. Planio из-за возраста продукта и пивота на команды пока не прошёл через этот же цикл в полной мере — блог как источник трафика на него ещё предстоит выстроить под новую, более широкую аудиторию: не только мастеров-одиночек, но и владельцев, которые выбирают систему для команды.

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

Метрики, которые я отслеживаю каждую неделю

Соблазн соло-разработчика — следить за метриками тщеславия: количество загрузок, лайки в твиттере, упоминания в чужих постах. Я сам купился на это в первые месяцы Cruxly: обновлял счётчик регистраций по несколько раз в день. Но большинство этих людей открывали продукт один раз и больше не возвращались.

Метрики, которые я смотрю сейчас: сколько пользователей вернулись после первого использования, сколько дошли до оплаты, и сколько времени я трачу на поддержку одного активного пользователя. Последняя первой убивает соло-продукт, если её не считать: рост числа пользователей легко оборачивается ростом часов в переписке с саппортом, а не в разработке. Для Cruxly сейчас это около 10 минут поддержки на активного пользователя в месяц. Для Planio выше: аудитория менее техническая и чаще пишет с вопросами вроде "как посмотреть маршрут на карте", а не с багрепортами.

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

Что я узнал о продажах, будучи инженером

Я учился программировать, а не продавать, и первые месяцы Cruxly это было видно по каждому касанию с потенциальным пользователем. Я писал фичи и ждал, что они сами объяснят себя. Не объясняют. Человек, который впервые открывает продукт, не читает документацию: он либо понимает ценность за первые тридцать секунд, либо закрывает вкладку.

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

Самое полезное, что я для себя вынес: продажа — не отдельный этап после того, как продукт готов, а часть самого продукта. Формулировка на главном экране, порядок полей в форме заявки, то, что показывается пользователю в первые секунды после регистрации: всё это продажа, даже если там нет ни одной кнопки "купить". Я переписывал первый экран Cruxly пять раз не потому, что менялся функционал, а потому что каждая версия текста по-разному объясняла, зачем это вообще нужно.

Это знание оказалось прямо применимо к Planio, хотя аудитория там совершенно другая. Мастер на выезде ещё менее склонен разбираться в интерфейсе, чем пользователь AI-инструмента: у него нет времени и часто нет привычки пробовать новый софт между заявками. А владелец бригады, который выбирает систему сразу для команды, смотрит на первый экран другими глазами: его интересует не "помогу ли я себе", а "выдержит ли это десять человек". Первый экран Planio должен убеждать за один взгляд обе аудитории сразу. Мне это далось сложнее, чем аналогичная задача для Cruxly: я компенсировал это тем, что специально собирал обратную связь у нескольких мастеров на ранней версии интерфейса — показывал экран без единого пояснения от меня и следил, за какую кнопку они попытаются нажать первой.

Соло-фаундерство и выгорание

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

Был конкретный момент, когда это перестало быть абстрактной проблемой. Однажды я двое суток пролежал с температурой, не в состоянии открыть ноутбук, и именно в эти дни у Planio начались проблемы с генерацией документов из-за обновления библиотеки, от которой зависела эта функция. Мастера получали ошибку и не понимали, куда обращаться: дежурной поддержки просто не существовало. Урок был неприятным: у продукта не было ни одного плана на случай, когда единственный человек физически не может работать.

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

Чему один продукт учит другой

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

Куда дальше

План на 2026-2027 год для обоих продуктов сводится к тому, чтобы довести существующую модель до устойчивого состояния, а не гнаться за кратным ростом любой ценой.

Для Cruxly это уже не про список фич. AI-блокнот, Второй мозг, Chrome-расширение, транскрибация, разбор веб-страниц — то, что ещё недавно было планом, уже работает в проде. Дальше задача менее эффектная, но не менее важная: довести качество каждого режима до состояния, когда он не подводит. Если тебе интересна структура этой ниши подробнее, я разбираю конкретные сценарии выбора инструмента в материале про AI-конспект видео и материале про AI-чат с PDF.

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

Ни один из этих планов не гарантирован. Я уже дважды видел, как уверенный план на квартал разваливался за первую же неделю из-за бага, который съел время, отведённое на что-то другое. Это, наверное, самое честное, что я могу сказать про соло-разработку двух продуктов: план существует, но живёт ровно до первого столкновения с реальностью, и умение быстро его пересобрать — единственная рабочая альтернатива тому, чтобы вообще его не строить.

Если ты сам сейчас решаешь, строить один продукт глубоко или несколько параллельно, у меня для тебя нет готового ответа. Правильный выбор зависит от вещей, которые я не могу знать за тебя: сколько времени у тебя реально есть в неделю и насколько ты готов быть единственным человеком, который отвечает за оба продукта ночью, если что-то сломается. У меня это решение сработало на текущем масштабе. Проверить, сработает ли оно на следующем, я смогу только когда до него доберусь.