Неделя 131. Три ставки: ИИ-напарник в понедельник, своя CRM в среду и сайт за выходные

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

Я Дмитрий Дьяконов, основатель Botseller AI. Это девятый выпуск серии «Ретроспектива», бортжурнал в прошлое: от настоящего к первому коммиту. В выпуске о неделе 132 я разбирал баг, открывавший чужие данные, и правило второго клиента. Сегодня отматываю ещё на неделю назад, на 2-8 февраля 2026 года. Честно скажу, почему я люблю этот жанр: git log помнит мои решения лучше, чем я сам. Если бы меня спросили в то воскресенье, что я делал всю неделю, я бы ответил «всё сразу и ничего до конца». А из будущего видно: это была самая важная неделя той зимы. Каждое из трёх решений имело развилку, у каждой развилки была ветка попроще, и каждый раз мы на неё не свернули. Разберу все три: почему взялся именно за это, именно тогда, что было на другой чаше весов и что из этого выросло.

Контекст: что было к началу недели

Февраль 2026 года, продукту около полугода. Боты отвечают клиентам в мессенджерах, есть личный кабинет, есть первые платящие клиенты. Дальше начинаются минусы. Нормального сайта нет: старый, на тяжёлом устаревшем движке, трогать страшно. Своей CRM нет: есть прототип под одного клиента из ниши детских центров. Команда крошечная, и список задач растёт быстрее, чем закрывается. Когда рук меньше, чем задач, выбор задачи и есть стратегия. Просто тогда я не называл это стратегией. Я называл это «горит».

Понедельник: новый член команды, у которого нет имени

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

Об этом решении история умалчивать не может, потому что git выдаёт всё. Пятнадцать коммитов той недели носят сообщения вида «Задача выполнена. Вот итоговое резюме:», «Готово!», «Компонент исправлен. Вот что было сделано:». Это вставленные ответы агента, которые я не глядя отправлял в историю вместо нормальных сообщений. В одно из них уехал целый служебный отчёт с внутренними идентификаторами. Смешно? Очень. Но я специально не вычищаю эти следы из рассказа: по ним видно живого человека, который осваивает новый инструмент на бегу, ошибается и учится.

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

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

Вторник: день, когда мы чуть не остались чужим плагином

Утро вторника по git log выглядит невинно: «Обновлена инструкция по подключению AmoCRM». Мы улучшали путь клиента в чужую CRM, как делали до этого не раз. У нас и гайд по интеграции с amoCRM есть, и с Битрикс24 мы дружим до сих пор. И именно в этот день развилка, которая зрела месяцами, встала в полный рост.

Ветка первая, разумная: остаться ботом-надстройкой. Бот отвечает в мессенджерах, а лидов складывает в amoCRM, Битрикс24, куда скажут. Меньше кода, быстрее продажи, рынок понятен. Одна беда: ты вечный гость. Живёшь по чужим правилам, упираешься в чужие лимиты, и главное, ценность оседает не у тебя. Ветка вторая, наглая: строить свою CRM в 2026 году, когда их на рынке сотни. Дольше, дороже, и все умные люди скажут «зачем».

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

Среда, 21:45: три коммита за пять минут

Развязка наступила в среду вечером. В 21:45 коммит в движок CRM, в 21:49 в интерфейс, в 21:50 в кабинет. Три репозитория за пять минут: у платформы появилась кнопка «включить CRM». Один вызов создаёт заказчику его собственную CRM: воронку, статусы, карточки. Повторное нажатие вежливо отвечает «уже включена». С этого вечера CRM перестала быть прототипом под одного клиента и стала частью платформы.

Деталь, которую я нежно люблю: шаблонов при рождении было два, «воронка продаж» и «детский центр». Идея, что CRM должна подстраиваться под нишу, а не ниша под CRM, оказалась зашита в ДНК с первого дня. Тогда это не выглядело архитектурным принципом: просто у нас был живой клиент из детских центров, и его мир нельзя было натянуть на универсальную «воронку продаж».

Была ли ветка, где мы остаёмся плагином? Была, и она не умерла, а заняла своё место: интеграции с чужими CRM живут до сих пор, через неделю мы будем отлаживать связку с Битрикс24 для клиента, которому так удобнее. Разница в том, что теперь это дороги от нашего дома, а не съёмные углы. Как решение развернулось, читатели серии уже знают: в пятницу той же недели прорастёт третий шаблон, через неделю сформулируется правило второго клиента, ещё через неделю CRM получит лицо за одну пятницу и со временем станет главным отличием продукта. Задним числом решение выглядит безальтернативным. Изнутри оно выглядело наглостью. Между этими двумя оценками и живёт вся польза ретроспективы.

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

Четверг и пятница: рассылки уезжают в ядро

Параллельно со средой и до пятницы шла третья стройка, самая незаметная снаружи: первая версия массовых рассылок. Логика по вебхуку, чекер, обработчик очереди, периодические задачи, которые сами запускают отправку. Классические грабли не заставили ждать: сравнение «пора ли отправлять» споткнулось о часовые пояса (таймзоны в тот февраль кусали нас каждую неделю), стоп-слово клиента переехало на уровень контакта, а Telegram быстро напомнил о своих лимитах на массовость.

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

Ночь пятницы, 23:57: шаблон «Тренажёрный зал»

В пятницу без трёх минут полночь в движке CRM появился третий шаблон: «Тренажёрный зал». В 00:19 субботы к нему подъехали безлимитные абонементы, реализованные самым честным способом: у безлимита просто нет счётчика посещений. Двое суток от кнопки «включить CRM» до третьей ниши.

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

Выходные: сайт за 48 часов и жадность на 598 статей

А теперь третья ставка. В пятницу в 22:47, за час до шаблона тренажёрного зала, случился первый коммит совершенно нового проекта: сайт. Не страница-визитка, а сразу настоящая стройка: контейнеры, автосборка, раздельный деплой. В субботу поднялись лендинг и блог, в воскресенье аналитика, домены, CDN и карта сайта на 599 адресов. От нуля до живого сайта прошло примерно 48 часов.

Самый тяжёлый коммит выходных весил 9176 файлов и 39 тысяч строк: блог, в который мы перенесли 598 статей со старого сайта. И вот тут была развилка, которую я разобрал бы сегодня иначе. Вариантов было три. Латать старый сайт: тупик, старый движок не давал ни скорости, ни контроля. Начать с чистого листа и бросить старый контент: страшно, «там же трафик». И третий, жадный, который я выбрал: новый сайт плюс перенести вообще всё. Все 598 статей, накопленных за годы, в новый блог одним коммитом.

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

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

А почему вообще сайт, и почему в те выходные? Потому что будни целиком съедала платформа, а сайт был классической «важной несрочной» задачей. Несрочной она была ровно до момента, когда я посчитал: каждый месяц без нормального сайта это месяц, в который нас не находят. Дальше произошло то, что происходит со всеми важными несрочными задачами, которым наконец назначили дедлайн: она заняла первые же свободные 48 часов.

Что я понял, глядя назад: критерий владения

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

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

И у каждой развилки была ветка проще: нанять на разовую задачу, интегрироваться и не выпендриваться, подлатать старый сайт. Каждая простая ветка оставляла нас арендаторами. Отсюда критерий, которым я с тех пор проверяю, за что браться в первую очередь, когда горит всё: если через год эта работа станет активом, который работает на тебя, бери сейчас. Если это обустройство съёмного угла, оно подождёт. Признаюсь честно: в ту неделю я так не думал, я просто тушил самое горящее. Паттерн проявился только в ретроспективе. Ради таких моментов я и веду эту серию: решения, которые изнутри выглядели паникой, снаружи оказались стратегией. Или наоборот, и это тоже полезно знать.

Цифры недели

• 95 коммитов в семи проектах за семь дней
• Около 80 тысяч добавленных строк, из них 68 тысяч: новый сайт
• 9176 файлов в одном коммите: блог с 598 перенесёнными статьями
• 599 адресов в первой карте сайта
• 48 часов от первого коммита сайта до живого продакшена
• 5 репозиториев получили инструкцию для ИИ-агента в один понедельник
• 15 коммитов с сообщениями, которые написал не человек
• 3 коммита за 5 минут: рождение BotsellerCRM в среду в 21:45
• 2 шаблона CRM при рождении, третий через двое суток в 23:57

Что было дальше

Дальше была неделя 132: баг, при котором пустой список прав открывал чужие данные, фронтенд для ночного шаблона тренажёрного зала и сто битых ссылок как первый счёт за жадный перенос контента. Ещё через неделю CRM, рождённая в среду тремя коммитами, получит интерфейс на семь тысяч строк за одну пятницу. А ставки недели 131 продолжают работать до сих пор: на сайте, который вы читаете, в CRM, которая ведёт лидов, и в темпе, который задал тот понедельник.

Все выпуски серии собраны в категории ретроспектива, а текущая хроника разработки продолжается в бортовом журнале.

FAQ

Что такое ретроспектива Botseller?

Серия «Ретроспектива», бортжурнал в прошлое: от настоящего к первому коммиту. Каждый выпуск разбирает одну неделю разработки платформы по реальным git-логам, с фокусом на развилки: почему выбрали именно эту задачу, какие были альтернативы и как решение развернулось спустя месяцы. Все выпуски собраны в категории ретроспектива.

Своя CRM или интеграция с amoCRM и Битрикс24: как выбрать?

Критерий: где рождается лид и кому нужны его данные. Если процессы компании уже живут в большой CRM, разумнее интеграция: бот собирает лидов в переписке и передаёт их в привычную систему, как в наших гайдах по amoCRM и Битрикс24. Если отдельной CRM нет, а продажи идут в мессенджерах, встроенная CRM выигрывает: лид, история диалога и воронка живут в одном месте без двойного ввода.

Зачем боту для переписки собственная CRM?

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

Стоит ли переносить весь старый контент при переезде сайта?

Наш опыт говорит: нет. Мы перенесли 598 статей со старого сайта, а через полтора месяца удалили большинство как мёртвый груз, потратив недели на битые ссылки и чистку. Правильный порядок: сначала аудит (какие страницы приносят переходы и позиции), потом перенос только живого с настройкой редиректов со старых адресов. Удалять страшно, но контент остаётся активом, только пока работает.

Как маленькой команде ускорить разработку с ИИ-агентами?

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

Почему массовые рассылки в мессенджерах сложнее, чем кажутся?

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