Как я сделал свою CRM вайбкодингом
Я экономист, а не программист. Моя компания Спецраз.рф оформляет спецразрешения на перевозку негабаритных и тяжеловесных грузов. С мая 2026 года я вместе с ИИ-агентами Claude Code и Codex собираю для неё систему управления заказами — СУЗ. Сейчас в ней работают 6 операторов. Ниже — как это было, без прикрас.
Готовые CRM я пробовал
Сначала был Trello, потом amoCRM. В итоге мы вернулись к Telegram и Google Таблицам.
Дело в том, что заказ на спецразрешение — не «сделка» в воронке. Он складывается из пяти разных вещей:
- бриф — откуда, куда, что везём, какие габариты и нагрузки на оси;
- построения маршрута в госсистеме Safe-Route, обычно несколько вариантов;
- документы — разрешения, госпошлины, счета;
- переписка с клиентом в Telegram, MAX, WhatsApp и по почте;
- оплаты.
Коробочная CRM знает про сделки и контакты, но ничего не знает про маршруты, сцепку тягача с прицепом и разрешения. Поэтому жили так: бот заводил на заказ тему в Telegram и строку в Google-таблице. Реестр заказов и реестр проектов — две таблицы, которые вели руками. Данные заявления и маршрута копировали тоже руками.
Мне не нужна была ещё одна CRM с воронкой. Нужна была понятная таблица всех заказов, где рядом лежит переписка с клиентом. Такую я и решил собрать.
Что получилось
Главный экран — карточка заказа. Слева карта с маршрутом, в центре чат клиента, справа бриф и габариты. Оператору не нужно переключаться между окнами.
- Все заказы в одном списке. Фильтры, статусы, и у каждого заказа виден следующий шаг.
- Бриф сохраняется на каждом поле. Если двое операторов правят один заказ, система не даст затереть чужие правки.
- Варианты маршрута лентой с предпросмотром на карте. Панель «Что мы уже знаем» подтягивает прошлые разрешения и построения по тому же направлению.
- Документы уходят клиенту только через проверку.
- Деньги. Робот смотрит банковские приходы и подсказывает, к какому заказу относится платёж. Отдельный экран сверяет счета и оплаты по каждому заказу.
- Чек-лист готовности и статус заказа из 9 шагов с подсказкой, что делать дальше.
С конца октября у СУЗ появились два робота-помощника:
- Администратор пять раз в день — в 8, 12, 15, 19 и 24 часа по Москве — присылает команде сводку по всем открытым заказам.
- Охранник следит, чтобы клиент не ждал ответа. 15 минут тишины — напоминание в теме заказа, 30 минут — тревога.
Как это строилось
- Конец 2025. Первая попытка — конечно же, с фронтенда. Несколько дней рисую в Figma ленту заказов.
- Май 2026. Плотно берусь за СУЗ.
- 2 июля. Первый экран: список заказов и сам заказ.
- 3 июля. Вход для команды, ссылка на конкретный заказ, карта и бриф.
- 4–9 июля. Реестр «Все заказы», заказ внутри мессенджера Omni, карточки клиентов.
- К 20 июля операторы уже работают в СУЗ — меньше трёх недель от первого экрана.
- 26 июля. Полноценное рабочее место: построения, бриф и заказ в одной правой панели.
- 10–12 августа. Вкладка «Построения»: варианты маршрута лентой и отправка построений в Safe-Route прямо из заказа.
- 12 сентября. Выкатка обновлений одной кнопкой с журналом.
- 21 сентября. Переделал вкладку «Построения» за 2 часа 43 минуты — от первого запроса до работы у операторов.
- 23–30 октября. Администратор и Охранник.
Дня большого релиза не было. Система растёт как прогрессивный JPEG: сначала грубая, но рабочая картинка, потом детали.
Как я работаю с ИИ-агентами
Я не пишу код. Моя работа — объяснить, что болит, и проверить, что стало лучше.
- Заметка. Голосом или текстом в Telegram, когда что-то неудобно мне или операторам.
- Задача. Бот превращает заметку в задачу на GitHub.
- План и макет. Claude Code разбирается в задаче и пишет план. Если меняется экран, сначала рисуется макет. Только для СУЗ их набралось 38, и каждый я посмотрел до того, как написан код.
- Код пишет Codex.
- Ревью. Второй ИИ-агент проверяет каждое изменение и ищет ошибки. Кругов проверки — не больше трёх, иначе можно шлифовать вечно.
- Выкатка — одна кнопка с журналом. Если что-то сломалось, откат той же кнопкой.
- Операторы работают и пишут, что неудобно. Круг замыкается.
С сентября задачи делятся на три дорожки по риску. Мелочи ИИ делает и выкатывает сам. Всё, что касается денег, записи в госсистему или необратимых действий, ждёт моего «делай».
Что пошло не так
Красивый макет в Figma. Начал я, конечно же, с фронтенда. Несколько дней с удовольствием рисовал в Figma, как должна выглядеть лента заказов. Этот дизайн так и остался в Figma. Настоящий интерфейс вырос из структуры базы данных и связей между страницами. Вывод: сначала решить, что хранится и как связано, а экран — потом.
Слишком строгое окно. Мы сделали окно «Добавить ТС» — завести машину клиента в госсистему. Ревью нашло кучу ошибок, исправляли в три круга. Запись в госсистему в итоге работала. А я сам не смог пройти через проверки в этом окне — их стало слишком много. С тех пор правило: сначала ядро, которое работает, потом проверки — по реальной боли. Новые проверки удобства — предупреждения, а не запреты. Запретами остаются только безопасность, целостность данных и защита от дублей.
Двойная заявка. После удачного пилота кнопки «Запустить построения» ревью нашло дыру: если перезагрузить страницу и нажать ещё раз, заявка может уйти в госсистему второй раз. Риск вынесли в отдельную задачу. Вывод: всё, что пишет во внешнюю систему, должно быть защищено от двойного нажатия.
Белый экран. После одного из обновлений рабочего места СУЗ открывалась белым экраном. Новую часть отключили, интерфейс пересобрали. Вывод: откат должен быть простым. Через полтора месяца появилась кнопка выкатки с откатом.
И что стало лучше. Сужу по себе. Раньше полное заведение заказа — от первого сообщения клиента до оплаты госпошлины — могло занять у меня час. Нужно было завести тему в Telegram и строку в таблице, переписать данные заявления и маршрута, найти оплату в банковской выписке и понять, на каком шаге заказ. Сейчас на то же уходит 15–20 минут. Бриф собирается из переписки, варианты маршрута лежат лентой в самом заказе, робот подсказывает, чей платёж, а статус показывает следующий шаг.
Цифры
- 6 операторов работают в СУЗ.
- Меньше 3 недель от первого экрана до работы операторов.
- До часа → 15–20 минут на полное заведение заказа: от сообщения клиента до оплаты госпошлины.
- ≈ 1 400 коммитов в коде СУЗ, ≈ 90 принятых пулл-реквестов.
- Больше 100 тысяч строк кода.
- 38 макетов экранов — до того, как написан код.
- 2 ч 43 мин — самая быстрая переделка: от запроса до прода.
Сколько это стоило
- Подписки на ИИ — $436 в месяц с налогом. Меньше уже не получается.
- Два сервера — около 7 000 ₽ в месяц. Один из них, под карту и СУЗ, довольно мощный.
- Моё время — чистые часы я не считал. По сути, почти весь мой день теперь — вайбкодинг, с перерывами на операционную работу, еду и прогулку.
Можно ли так же у вас
Если вы уже пробовали вайбкодинг сами и упёрлись — в архитектуру, в выкатку, в то, что ИИ ломает работающее, — напишите. Расскажу, как можно сделать такое для вас.