Как я строю AI-продукты соло: опыт разработки Cruxly и Planio
Два продукта, ни одного сооснователя. Разбираю, как я выбираю, что строить, где в этом участвует Claude Code, почему Planio совсем не похож на Cruxly и что из этого провалилось раньше, чем взлетело.
Почему два продукта, а не один
У меня нет сооснователя, нет инвестора и нет отдела, который отвечает за что-то, пока я сплю. Есть я, ноутбук и два продукта, которые я строю параллельно: Cruxly, AI-инструмент для конспектирования видео и PDF, и Planio, приложение для мастеров на выезде вроде сантехников и электриков. На первый взгляд это выглядит как распыление внимания. На практике это осознанное решение, и в этом тексте я разбираю логику за ним: как я выбираю, что строить, где в этом реально участвует Claude Code, а не только в написании кода, и что из этого уже провалилось, прежде чем начало работать.
Я пишу этот текст не как советы "как тебе тоже запустить продукт соло". У меня нет миллионных выходов и нет права поучать. Есть конкретный опыт двух запусков разного типа продукта в разное время, и то, что я из этого вынес, может быть полезно, если ты сейчас решаешь ту же задачу: строить одну вещь глубоко или несколько вещей параллельно, рискуя не довести ни одну до конца.
Прежде чем идти дальше, стоит сразу назвать то, чего в этом тексте не будет. Не будет истории успеха с красивой аркой "было тяжело, стало прекрасно". Оба продукта на момент написания этого текста находятся в процессе, а не в точке, где можно подводить итог. Часть решений, которые я здесь описываю, ещё не проверена временем и вполне может оказаться ошибкой, которую я разгляжу только через год. Я предпочитаю написать это сейчас, пока решения свежие и я ещё помню, почему принял их именно так, а не задним числом переписывать историю под уже известный результат.
Cruxly и Planio отличаются друг от друга не только по функционалу, но и структурно, и это отличие определяет буквально каждое решение дальше в этом тексте. Cruxly — AI-продукт в буквальном смысле: без языковой модели внутри его просто не существует, вся ценность продукта строится вокруг качества генерации. Planio использует AI разве что во вспомогательных местах. По сути это обычное B2B-приложение для конкретной отрасли, где основная ценность: правильно спроектированный рабочий процесс, а не генерация текста. Держать в голове эту разницу полезно, потому что дальше я буду то и дело сравнивать два продукта, которые на самом деле принадлежат к разным категориям, и выводы, применимые к одному, не всегда переносятся на другой без поправки.
Как появился Cruxly
Идея Cruxly выросла из раздражения, а не из рыночного исследования. Я готовился к докладу на митапе разработчиков и обнаружил, что трачу больше времени на пересказ того, что я уже посмотрел или прочитал, чем на само содержание. Часовое видео превращалось в конспект на полчаса работы руками: пересматривать, останавливать, записывать тезисы, возвращаться назад, потому что пропустил важный момент.
Я не сразу понял, что это готовая идея продукта. Первую пару недель я просто собирал костыль для себя: скрипт, который вытаскивал субтитры и прогонял их через модель с промптом на конспект. Он работал криво, путал таймкоды и иногда обрезал важный кусок посередине, но экономил час на каждом видео, и этого хватило, чтобы я продолжал им пользоваться. Момент, когда я решил превратить костыль в продукт, случился, когда знакомый попросил "прислать ту штуку, которой ты конспектируешь лекции" — то есть спрос появился раньше, чем я успел его специально поискать.
Первая версия Cruxly решала ровно эту задачу и ничего больше: скармливаешь ссылку на видео или PDF, получаешь структурированный конспект с таймкодами и возможностью задать уточняющий вопрос по содержимому. Никакого маркетингового сайта, никакой регистрации через соцсети, просто форма и результат. Я тестировал её на себе две недели и только после этого показал десяти знакомым, чтобы понять, ловит ли она чужую, а не только мою собственную боль. Часть отзывов была неприятной: два человека сказали, что конспект слишком длинный, и честно признались, что читать его целиком всё равно не станут. Им хватило бы трёх предложений сути и ссылки на нужный таймкод, остальное они просто пролистают. Я почти проигнорировал это как частный случай одного вкуса, а потом получил тот же комментарий третий раз от совершенно не связанного с первыми двумя человека и понял, что это закономерность, а не совпадение вкусов. Переделал формат вывода: сначала три строки сути, дальше развёрнутый конспект по желанию, а не наоборот.
Здесь стоит признать прямо: рынок AI-конспектирования видео и документов не пустой. NotebookLM от Google решает похожую задачу и не берёт денег за базовое использование, потому что работает поверх инфраструктуры Google. Я не стал делать вид, что это не так. Вместо этого я сфокусировался на нише, где такой инструмент избыточен: быстрый разовый конспект без необходимости заводить проект, загружать источники пачкой и разбираться в интерфейсе, рассчитанном на многочасовую исследовательскую работу.
Разница в сценарии использования оказалась важнее разницы в качестве модели. NotebookLM рассчитан на сценарий, где у тебя уже есть папка источников и ты работаешь с ними неделями, постепенно накапливая контекст внутри одного проекта. Копировать эту логику я не стал специально. Вместо неё я построил ровно противоположный сценарий: одна ссылка, один запрос, результат за минуту, без необходимости заводить учётную запись под конкретный проект и без интерфейса, который предполагает многодневную работу там, где человеку нужно решение одной конкретной задачи прямо сейчас. Это и есть Cruxly. Если тебе интересна сама механика этой ниши и почему NotebookLM не закрывает её полностью, я разбираю это подробнее в материале про NotebookLM и альтернативы.
Как появился Planio
Planio — полная противоположность Cruxly по логике происхождения. Я не столкнулся с этой проблемой лично: я не сантехник и не электрик. Идея появилась из наблюдения за тем, как устроен рынок инструментов для мастеров на выезде в России и СНГ: фрагментированный, без одного доминирующего игрока вроде NotebookLM в нише Cruxly, с несколькими игроками среднего размера вроде Планадо, RO App и HelloClient, каждый из которых закрывает часть задачи, но не всю.
За этим наблюдением стоит один конкретный разговор, а не абстрактный анализ рынка. Знакомый мастер по ремонту техники жаловался, что ведёт заявки в блокноте и путается, кому и когда обещал приехать, а из трёх приложений, которые он пробовал, каждое либо стоило дороже, чем он готов платить на старте, либо требовало больше настройки, чем у него было свободного времени между вызовами. Я послушал, потом задал ещё несколько вопросов другим знакомым в похожих профессиях, от сантехника до электрика, и увидел один и тот же паттерн: не отсутствие инструментов, а отсутствие простого входа в них.
Мастер на выезде решает одну и ту же задачу каждый день: принять заявку, оценить стоимость, построить маршрут, зафиксировать статус работы, выставить документ клиенту. Planio закрывает это одним приложением: онлайн-запись 24/7, календарь с маршрутом на карте, статусы заявок, база клиентов, расчёт стоимости, автогенерация документов, учёт финансов. Слоган продукта прямо описывает суть: заявки, клиенты и расписание для мастеров на выезде в одном приложении.
Прежде чем строить Planio, я потратил время на то, чтобы честно посмотреть на существующих игроков этого рынка: Планадо, RO App, HelloClient, Lubava, РеМастер. Каждый из них закрывает часть той же задачи, и ни один не выглядит откровенно слабым продуктом, который легко обойти на голом энтузиазме. Но у каждого нашёлся свой перекос: где-то сложная настройка, которая отпугивает мастера-одиночку без технической подготовки, где-то интерфейс, спроектированный явно под более крупную бригаду, а не под одного человека с одним телефоном в кармане. Задача была не придумать что-то принципиально новое, а собрать вместе то, что у конкурентов разбросано по разным продуктам или спрятано за сложной настройкой.
Решение строить именно это, а не второй AI-инструмент, было стратегическим, а не случайным. Я не хотел, чтобы весь портфель зависел от одной категории продуктов, которая может быть подорвана одним обновлением модели от OpenAI или Google. Field-service CRM — скучная категория с точки зрения хайпа и устойчивая с точки зрения спроса: мастерам нужно принимать заявки и вести клиентов независимо от того, что происходит с LLM в этом квартале.
Диверсификация здесь работает так же, как в любом другом портфеле: не класть всё в одну корзину, даже если корзина сейчас модная. Я видел, как несколько знакомых соло-разработчиков построили весь бизнес вокруг тонкой обёртки над чужим API, а потом смотрели, как их продукт становится не нужен после одного релиза от самой модели-провайдера. Мне не хотелось повторять эту ошибку во второй раз, тем более что первый продукт у меня уже был именно в этой рискованной категории.
С технической стороны Planio устроен проще, чем Cruxly, и это тоже сознательный выбор. Здесь нет зависимости от качества генерации языковой модели, а значит нет и риска, что продукт внезапно станет хуже из-за изменения в чужом API. Основная сложность лежит в деталях, а не в алгоритмах: правильно посчитанный маршрут с учётом реальных пробок, корректно сгенерированный документ под требования конкретного вида работ, интерфейс, который не путает мастера, открывающего приложение на бегу между двумя заявками, а не сидя за компьютером. Ни одна из этих задач не сложна сама по себе, но их нужно решить одновременно и без права на заметный сбой, потому что мастер, которому приложение не помогло в разгар рабочего дня, вряд ли откроет его во второй раз.
Соло против команды: что я потерял и что выиграл
Решение вести оба продукта в одиночку, а не искать сооснователя или нанимать команду, — это конкретный компромисс, а не идеология. Я потерял скорость: там, где команда из трёх человек параллелит фронтенд, бэкенд и продажи, я делаю всё последовательно, и это физически ограничивает, сколько всего может произойти за неделю. Я потерял второе мнение в реальном времени. Когда решение спорное, обсудить его можно только с самим собой, а это заведомо хуже, чем спор с человеком, у которого другой опыт и другие слепые пятна.
Конкретный пример этой потери: я почти полгода откладывал решение сменить модель ценообразования Cruxly с разовой оплаты на подписку, потому что не был уверен и некому было проверить интуицию до того, как я потрачу время на переделку. С сооснователем этот разговор занял бы час. В одиночку я вместо разговора собирал косвенные признаки: сравнивал похожие продукты, читал форумы, откладывал решение снова, и в итоге принял его позже, чем стоило бы, просто потому что боялся ошибиться без второго мнения рядом.
Что я выиграл взамен — это скорость решений другого рода: скорость выбора направления, а не скорость исполнения. Не нужно согласовывать пивот с сооснователем, который вложил полгода в другую гипотезу. Не нужно объяснять инвестору, почему я закрываю фичу, в которую верил три месяца назад. Когда стало понятно, что первая версия ценообразования Cruxly отпугивает именно тех пользователей, которых я хотел удержать, я поменял её за один вечер, потому что решение принимает один человек, и оно не проходит через согласование.
Соло-разработка — это не идеология, а компромисс с конкретной ценой в обе стороны, и я не считаю его универсально правильным выбором. Для Cruxly и Planio на текущем этапе он работает, потому что оба продукта достаточно маленькие, чтобы один человек физически успевал вести и код, и продукт, и минимальную поддержку. Если любой из них вырастет настолько, что я перестану успевать, этот баланс придётся пересматривать, и я предпочитаю признать это заранее, а не удивляться, когда это случится. Я видел достаточно историй, где соло-фаундер держался за единоличный контроль на фазе, где продукт уже требовал команду, и продукт от этого страдал куда сильнее, чем от гипотетической потери контроля.
Где в этом на самом деле участвует Claude Code
Про использование AI-ассистентов в написании кода я подробно писал в материале про практический workflow с Claude Code. Весь этот сайт, включая текст, который ты сейчас читаешь, написан в такой связке. Но для Cruxly и Planio Claude Code участвует не только в коде. Он участвует в продуктовых решениях: разборе структуры базы данных перед тем, как её менять, формулировке пользовательских сценариев перед тем, как писать интерфейс, поиске edge cases в бизнес-логике до того, как их найдёт живой пользователь.
Конкретный пример прямо из практики этого же сайта. Пока я писал этот текст в паре с Claude Code, всплыл реальный баг в CMS: при повторном сохранении поста возникала ошибка published: invalid type: integer 1, expected a boolean. Причина оказалась банальной: бэкенд отдаёт булево поле как целое число из SQLite, а форма на фронтенде отправляет его обратно как есть, без явного приведения типа. Работает при первом сохранении, потому что значение приходит из формы уже булевым, и ломается при втором, потому что значение успело пройти цикл через GET-ответ сервера. Я не заметил бы этого до продакшена, если бы не наткнулся на него, работая руками. Ни один автотест не был написан на этот конкретный сценарий, потому что я не думал, что он вообще возможен.
Это ровно тот тип бага, который типичен именно для соло-разработки: некому посмотреть код свежим взглядом перед мерджем, некому спросить "а что если это поле придёт не в том типе". Claude Code в такой ситуации не заменяет ревьюера-человека, но частично компенсирует его отсутствие. Можно попросить агента специально поискать похожие несоответствия типов по всей кодовой базе вместо того, чтобы чинить один конкретный случай и надеяться, что больше таких нет. Я прогнал именно такой запрос сразу после фикса и нашёл ещё одно похожее место в другой форме, которое пока не успело сломаться, но было той же природы.
Похожая история случилась раньше с транслитерацией кириллицы в слаге поста: буквы "ь" и "ъ" должны были просто исчезать при генерации URL, а вместо этого проскакивали в латинице необработанными. Причина оказалась в паттерне map[c] || c — для этих двух букв в таблице транслитерации стояла пустая строка, JavaScript посчитал её ложным значением и откатился к оригинальному символу вместо ожидаемой пустой замены. Формально код был написан правильно с точки зрения синтаксиса и совершенно неправильно с точки зрения логики, и такую ошибку тяжело поймать одним взглядом на диф, потому что строка выглядит абсолютно невинно.
В Planio такой же класс проблем возникает в бизнес-логике, а не в коде, и там его труднее поймать, потому что нет синтаксической ошибки, которую подсветит компилятор. Пример: расчёт стоимости выезда мастера завязан на расстояние до клиента, и на этапе проектирования я не подумал о случае, когда у клиента есть только номер телефона, а адрес вообще не указан, потому что заявку приняли по звонку. Формула молча считала расстояние от нуля до координат мастера и выдавала абсурдно маленькую цифру. Я попросил агента специально пройтись по всей цепочке расчёта стоимости и явно перечислить, какие поля считаются обязательными, а какие могут отсутствовать, и на какое поведение рассчитан код в каждом случае отсутствия. Из этого разбора всплыло ещё два похожих места, которые я не заметил бы, если бы просто чинил конкретный баг с адресом и закрывал тикет.
Ценность Claude Code здесь не в том, что он написал код без единой ошибки с первого раза — не написал, обе ошибки в него закрались обычным образом. Ценность в скорости, с которой можно локализовать причину и проверить всю кодовую базу на похожие случаи, когда баг всё-таки найден. Раньше на такой цикл "нашёл, понял причину, проверил, нет ли того же в других местах" у меня уходил вечер. Сейчас это занимает от силы полчаса, и именно это время я получаю обратно для продуктовых решений, а не для рутинного поиска по коду.
Ценообразование и позиционирование в двух разных нишах
Cruxly и Planio конкурируют в нишах с принципиально разной структурой, и это напрямую определяет, как я их продаю. У Cruxly есть один крупный конкурент в нише: NotebookLM от Google, бесплатный для базового использования, потому что работает на инфраструктуре Google. Любая стратегия ценообразования обязана это учитывать: конкурировать по цене с бесплатным продуктом не имеет смысла как отдельная стратегия. Вместо этого Cruxly продаёт скорость и простоту разового использования там, где NotebookLM требует завести проект и разобраться в интерфейсе, рассчитанном на длинную исследовательскую сессию.
Первая версия ценообразования Cruxly была ошибкой, и я признаю это прямо. Я скопировал стандартную для SaaS модель подписки, потому что "так делают все", не подумав, подходит ли она сценарию разового использования. Человек, который заходит один раз в месяц конспектировать одно видео, не станет платить за подписку ради этого одного раза, сколько бы ценности она ни несла. Я увидел это по конверсии из пробного использования в оплату, которая упорно оставалась низкой, хотя отзывы на сам продукт были хорошими. Переход на модель с разовой оплатой за пакет конспектов вместо ежемесячной подписки поднял конверсию заметно, потому что она наконец совпала с реальным паттерном использования, а не с моделью, которую я взял по инерции из чужих продуктов.
У Planio ситуация другая: ниша фрагментирована между несколькими игроками среднего размера, ни один из которых не доминирует настолько, чтобы новому продукту приходилось объяснять пользователю, зачем ему альтернатива уже привычному инструменту. Здесь решение о цене — это не защита от одного крупного конкурента, а вопрос, где именно между существующими игроками встать: дороже и с более полным функционалом, дешевле и проще для мастера-одиночки без наёмных сотрудников, или где-то между. Я выбрал вход через бесплатный старт: мастер видит ценность на реальных заявках прежде, чем платит за что-либо, а не читает маркетинговый текст с обещаниями.
Разница в подходе к этим двум продуктам показывает то, что я не сразу понял на старте: универсальной формулы ценообразования для "AI-продукта соло-разработчика" не существует. Формула зависит от структуры конкретной ниши, доминирующий игрок или фрагментированный рынок, а не от того, что продукт сделан одним человеком. Я потратил на первую ошибку Cruxly больше времени, чем хотел бы признавать, именно потому что искал единый рецепт вместо того, чтобы с самого начала спросить, как именно пользователь платит за похожие вещи в этой конкретной нише.
Есть ещё одна деталь, которую я упустил на старте у обоих продуктов: цена психологически считывается не только как цифра, но и как сигнал о серьёзности продукта. Слишком низкая цена у Planio читалась частью мастеров как "значит, там мало функций" — им нужно было объяснение, почему цена именно такая, а не просто ценник без контекста. У Cruxly обратная ситуация: аудитория, привыкшая к бесплатному NotebookLM, реагирует на любую цену вопросом "а зачем платить, если есть бесплатное". Ответ на этот вопрос пришлось буквально вписывать в текст рядом с ценой, а не полагаться на то, что разница в сценарии использования будет очевидна сама по себе.
Первые пользователи без бюджета на маркетинг
У меня никогда не было рекламного бюджета ни на один из двух продуктов, и я не планирую его заводить в обозримом будущем. Модель, которая реально работает в моём случае: трафик из блога. Каждый пост в этом блоге пишется как самостоятельный, полезный текст под конкретный информационный запрос, и только внутри него, там, где это органично, стоит контекстная ссылка на Cruxly или Planio, а не баннер и не призыв "попробуй бесплатно" в шапке.
Я пробовал и другие каналы до того, как остановился на этой модели. Продакт-хант принёс всплеск посещений в день запуска и почти ничего после: люди, которые листают такие площадки, ищут новизну, а не решение конкретной задачи, и большинство из них не вернулись даже на второй день. Пост в тематическом сабреддите собрал бурное обсуждение в комментариях и почти ноль регистраций, потому что аудитория там пришла спорить о продукте, а не пробовать его. Оба канала дали быстрый, но короткоживущий всплеск, который не оставил после себя ничего, что продолжало бы работать через месяц.
Блог устроен принципиально иначе. Эта модель медленнее платной рекламы и требовательнее к качеству самого контента: если пост написан ради ссылки, а не ради читателя, поисковик и сам читатель это быстро считывают, и ссылка перестаёт что-либо приносить. Но у неё есть свойство, которого нет ни у рекламы, ни у продакт-ханта: она продолжает приводить людей и через год после публикации, без дополнительных вложений, пока пост актуален и продолжает ранжироваться в поиске.
Первых 50 пользователей Cruxly мне принесли именно несколько постов о рабочих процессах с AI, а не продакт-хант и не таргетированная реклама: ссылка на инструмент там оказалась логичным следующим шагом для человека, который уже читал про конспектирование источников и как раз искал что-то для этой задачи. Planio из-за возраста продукта пока не прошёл через этот же цикл в полной мере. Блог как источник трафика на него ещё предстоит выстроить, и это одна из конкретных задач на ближайшие месяцы, а не абстрактное намерение когда-нибудь этим заняться.
Место ссылки внутри поста имеет значение не меньше, чем сам факт её наличия. Ссылка, вставленная в первый абзац просто потому, что туда легче её воткнуть, работает заметно хуже, чем ссылка в том месте текста, где читатель уже сформулировал для себя конкретный вопрос, а инструмент отвечает именно на него. Я специально держу для себя правило: одна статья линкует на продукт максимум в одном-двух местах, там, где это органично по смыслу абзаца, а не в каждом разделе подряд ради максимизации кликов. Пост, который выглядит как список поводов кликнуть на продукт, читатель считывает мгновенно, и это разрушает доверие быстрее, чем полное отсутствие ссылок вообще.
Метрики, за которыми я на самом деле слежу
Соблазн соло-разработчика — следить за метриками тщеславия: количество загрузок, лайки в твиттере, упоминания в чужих постах. Ничего из этого не говорит, окупается ли время, которое я вкладываю в продукт. Я сам купился на это в первые месяцы Cruxly, обновляя счётчик регистраций несколько раз в день и радуясь каждому новому имени в списке, хотя большинство этих людей открывали продукт один раз и больше не возвращались. Метрики, которые я на самом деле смотрю каждую неделю сейчас: сколько пользователей вернулись после первого использования, сколько из них дошли до оплаты, и сколько времени я лично трачу на поддержку одного активного пользователя.
Последняя метрика — та, которую чаще всего игнорируют, и та, что первой убивает соло-продукт. Продукт может расти по числу пользователей и одновременно съедать всё больше моего личного времени на тикеты поддержки, пока не окажется, что рост числа пользователей на самом деле означает рост часов, которые я трачу на переписку в саппорте, а не на разработку. Для Cruxly сейчас это 10 минут поддержки на активного пользователя в месяц, для Planio выше, потому что аудитория менее техническая и чаще пишет с вопросами вроде "как посмотреть маршрут на карте", а не багрепортами.
Я специально считаю эту метрику по каждому продукту отдельно, а не суммарно, потому что портфель из двух продуктов легко создаёт иллюзию, будто время распределяется поровну. На практике оно почти никогда не распределяется поровну: одну неделю Planio требует внимания из-за наплыва новых вопросов от мастеров, следующую неделю Cruxly требует фикса после релиза новой версии модели, от которой изменился формат ответа. Без отдельного счётчика по каждому продукту я бы не заметил, что de facto три недели подряд занимаюсь только одним из двух, а второй в это время буквально стоит на месте.
Что я узнал о продажах, будучи инженером
Я учился программировать, а не продавать, и первые месяцы Cruxly это было видно по каждому касанию с потенциальным пользователем. Я писал фичи и ждал, что они сами объяснят себя. Не объясняют. Человек, который впервые открывает продукт, не читает документацию и не разбирается методом проб. Он либо понимает ценность за первые тридцать секунд, либо закрывает вкладку.
Первая версия главного экрана Cruxly начиналась с описания технологии: какая модель используется, как устроен конвейер обработки видео, почему это технически сложная задача. Инженеру такое описание кажется убедительным, потому что оно отвечает на вопрос "как это работает". Пользователю нужен ответ на другой вопрос: "что я получу и зачем мне это". Я понял разницу только после того, как посмотрел, на каком именно экране люди чаще всего закрывали вкладку, не дойдя до формы ввода ссылки, и увидел, что это ровно тот первый экран с техническим описанием.
Самое полезное, что я для себя вынес: продажа — это не отдельный этап после того, как продукт готов, а часть самого продукта. Формулировка на главном экране, порядок полей в форме заявки, то, что показывается пользователю в первые секунды после регистрации: всё это продажа, даже если там нет ни одной кнопки "купить". Я переписывал первый экран Cruxly пять раз не потому, что менялся функционал, а потому что каждая версия текста по-разному объясняла, зачем это вообще нужно, пока не осталась версия, которая формулирует результат раньше, чем технологию.
Это знание оказалось прямо применимо к Planio, хотя аудитория там совершенно другая. Мастер на выезде ещё менее склонен разбираться в интерфейсе, чем пользователь AI-инструмента: у него нет времени и часто нет привычки пробовать новый софт методом тыка между заявками. Первый экран Planio должен был объяснить пользу за один взгляд, а не за сессию использования, и это далось мне сложнее, чем аналогичная задача для Cruxly, потому что интуиция инженера здесь работает хуже, чем интуиция человека, который сам когда-то был мастером на выезде. Я компенсировал это тем, что специально собирал обратную связь у нескольких мастеров на ранней версии интерфейса, показывая им экран без единого пояснения от меня и следя, за какую кнопку они попытаются нажать первой, а не полагался на собственное чувство удобства.
Соло-фаундерство и выгорание
Ведение двух продуктов параллельно без команды создаёт особый тип нагрузки, который отличается от обычной переработки. Дело не в количестве часов. Дело в том, что ответственность никогда не переключается на кого-то другого, даже на выходных, даже в отпуске. Если ночью падает сервер Planio, чинить его буду я, независимо от того, что запланировано на завтра.
Был конкретный момент, когда это стало не абстрактной проблемой, а реальным сбоем. Однажды я двое суток пролежал с температурой, не в состоянии открыть ноутбук, и именно в эти дни у Planio начались проблемы с генерацией документов из-за обновления библиотеки, от которой зависела эта функция. Мастера, которые пытались выставить документ клиенту, получали ошибку и не понимали, куда обращаться, потому что дежурной поддержки просто не существовало. Я узнал об этом только вернувшись к работе, из накопившихся писем, и это был неприятный урок: у продукта не было ни одного плана на случай, когда единственный человек физически не может работать.
Я подробно разбираю механику выгорания и то, что реально помогает с ним справляться, в материале про профилактику выгорания. Тот текст не привязан к разработке продуктов конкретно, он про выгорание в целом, у кого угодно, не только у соло-фаундеров. Но применительно именно к ситуации "два продукта, один человек" я вынес одно конкретное правило, которое соблюдаю жёстко после того случая: у обоих продуктов должен быть способ работать без моего немедленного вмешательства хотя бы сутки. Это не значит нанять человека на дежурство, на моём масштабе это нереалистично. Это значит мониторинг, который сам перезапускает упавший процесс, автоматические бэкапы без ручного шага, и честный ответ пользователю в духе "ответим в течение суток" вместо иллюзии круглосуточной поддержки, которую я физически не могу обеспечить.
Это правило далось не сразу. Первая версия мониторинга просто присылала мне уведомление о падении сервера, что технически работает, но ничего не решает, если я в тот момент не могу встать с кровати. Пришлось отдельно настраивать автоматический перезапуск для тех сбоев, которые обычно чинятся простым рестартом процесса, и только для более редких и серьёзных случаев оставить уведомление, требующее моего ручного вмешательства. Разница между "уведомить меня" и "починить само, а меня уведомить только если не получилось" оказалась ровно той разницей, которая позволяет один раз заболеть, не потеряв продукт целиком.
Чему один продукт учит другой
Я не веду Cruxly и Planio как две изолированные вселенные, хотя категории у них разные. Часть решений в одном продукте прямо выросла из опыта, полученного во втором, и это одно из немногих реальных преимуществ ведения двух продуктов одновременно, а не по очереди.
Из Cruxly в Planio перешла дисциплина быстрого прототипирования интерфейса перед тем, как писать бэкенд под него. В AI-продукте это естественно: сначала смотришь, какой формат ответа модели реально понятен человеку, и только потом строишь код вокруг этого формата. Я перенёс ту же последовательность в Planio, хотя там нет модели, чей вывод нужно подстраивать. Сначала бумажный макет экрана заявки, показанный тому самому знакомому мастеру, и только после его правок — реальная схема базы данных под этот экран, а не наоборот, как я делал бы по инерции инженера.
Из Planio в Cruxly перешло другое: терпение к медленным, некрасивым, но надёжным решениям. В мире AI-продуктов легко увлечься тем, что можно сделать эффектнее с помощью более новой модели или более сложного промпта, и потерять из виду базовую надёжность: что произойдёт, если API модели недоступен, если ответ пришёл в неожиданном формате, если пользователь загрузил файл, который парсер не умеет читать. Работа над Planio, где сбой означает, что реальный мастер не может закрыть реальную заявку у реального клиента, приучила меня относиться к обработке ошибок серьёзнее и в Cruxly тоже, а не оставлять эти случаи "на потом", как раньше.
Куда дальше
План на 2026-2027 год для обоих продуктов сводится к тому, чтобы довести существующую модель до устойчивого состояния, прежде чем добавлять что-то новое, а не гнаться за кратным ростом любой ценой. Для Cruxly это означает более узкую специализацию под сценарии, где NotebookLM объективно избыточен, а не попытку догнать его по широте функциональности. Это осознанный выбор ниши, а не гонка, в которую имеет смысл ввязываться только потому, что можно попытаться. Если тебе интересна структура этой ниши подробнее, я собрал разбор конкурентов и того, чем конкретно можно закрыть нишу рядом с большим игроком, в материале про AI-конспект видео и материале про AI-чат с PDF.
Для Planio план ближе к базовому, чем к амбициозному: довести блог до состояния, когда он реально приводит мастеров, а не только читателей про AI и продуктивность. Это значит написать материалы под запросы, которые ищет именно эта аудитория, а не переиспользовать существующий блог по касательной, и, возможно, завести отдельный кластер статей под эту нишу, если объём материала окажется достаточным. Отдельная задача, которую я пока сознательно откладываю: понять, какая из фич, о которых просят мастера в поддержке, действительно нужна многим, а какая — частный случай одного клиента, который не стоит превращать в общую фичу продукта.
Есть и организационная задача, не связанная напрямую ни с одним из продуктов: пересобрать саму модель "блог приводит трафик на проекты" так, чтобы она масштабировалась на третий продукт, если он появится, без необходимости каждый раз придумывать всё заново. Сейчас у меня есть рабочая связка тегов и контекстных ссылок для двух кластеров, Cruxly и будущего кластера Planio, и уже видно, какие места в этой схеме придётся переделать, если добавится третий продукт в третьей нише. В первую очередь это правила, по которым решается, какому продукту достаётся ссылка из пограничного, не привязанного жёстко к одной теме поста.
Ни один из этих планов не гарантирован. Я уже дважды видел, как уверенный план на квартал разваливался за первую же неделю из-за бага, который съел время, отведённое на что-то другое. Тот самый баг с булевым полем в CMS случился ровно тогда, когда я планировал писать этот раздел, а не чинить чужой код, и мне пришлось на день отложить текст ради фикса, потому что публикация постов, которые как раз приводят читателей на оба продукта, важнее графика написания статьи про то, как я строю продукты.
Это, наверное, самое честное, что я могу сказать про то, как реально выглядит соло-разработка двух продуктов: план существует, но он живёт ровно до первого столкновения с реальностью, и умение быстро пересобрать его — единственная рабочая альтернатива тому, чтобы вообще не строить план. Я не жду, что в следующем квартале станет проще. Я жду, что научусь быстрее замечать, когда план разошёлся с реальностью, и это ровно та компетенция, ради которой имеет смысл писать подобные тексты хотя бы для себя, если не для читателя.
Если ты сам сейчас решаешь, строить один продукт глубоко или несколько параллельно, у меня для тебя нет готового ответа, потому что правильный выбор здесь зависит от вещей, которые я не могу знать за тебя: сколько времени у тебя реально есть в неделю, готов ли ты к тому, что оба продукта будут расти медленнее, чем один, и насколько ты готов быть единственным человеком, который отвечает за оба ночью, если что-то сломается. У меня это решение сработало на текущем масштабе. Проверить, сработает ли оно на следующем, я смогу только когда до него доберусь.
Комментарии
Комментариев пока нет. Будь первым.