Leonard Babakov - solo product engineer_
Пишу CRM и мобильные приложения под ключ
Это не портфолио агентства - я работаю один, от бизнес-задачи до кода: технология здесь средство, не цель. Ниже - реальные проекты, каждый сам довёл до результата, который видно в цифрах.
Кейс 01
ТвойCRM под конкретный бизнес
в продеCRM разворачиваю под конкретный бизнес - никакой готовой коробки с зашитыми полями. Термины, стадии сделок, типы клиентов настраиваются в справочниках, без правки кода. Школы и дистрибьюторы - готовые вертикали уже сегодня, частный случай платформы, не её потолок.
Заявка из Telegram-бота или голосовая заметка менеджера сама попадает в карточку сделки - никто не тратит вечер на перенос переписки в таблицу. У каждого клиента - своя отдельная база: чужие данные физически не смешиваются с вашими, даже по ошибке.
- 5 компаний работают уже сейчас, каждая в своей отдельной базе данных
- Ежедневные резервные копии на отдельном сервере, восстановление проверено вручную
- Обновления выкладываются одной командой и откатываются сами, если что-то пошло не так
- Документация - часть сдачи проекта: что сделано, почему и как это работает, веду и обновляю по ходу работы, не задним числом
- Тот же движок стал основой аналитического модуля для CRM клиента (Кейс 03) и линии Telegram-ботов (Кейс 04) - платформа оказалась шире одного клиентского проекта
- Написана с нуля - под новый бизнес достаточно завести справочники, ядро трогать не нужно
Как это устроено
Изоляция данных - на уровне базы: у каждого клиента своя схема Postgres и свои
политики Row Level Security - никакого общего флага tenant_id
поверх одной таблицы. Термины, стадии сделок и поля читаются из справочников -
под нового клиента с другой терминологией не нужен деплой.
Заявки из Telegram-бота и голосовые заметки менеджеров попадают в CRM через n8n - без no-code коннекторов, прямыми запросами к Telegram Bot API и REST. Голос проходит AI-структуризацию перед тем как лечь в карточку сделки. Инфраструктура своя: VPS, self-hosted Supabase, свой n8n, своя аналитика - сам решаю, что живёт на своём сервере, а что уходит во внешний API.
Документация ведётся по ходу работы, не пишется задним числом под сдачу: тематический журнал решений и ошибок (n8n, деплой, фронтенд, доступы, БД), живая схема базы, карта архитектуры, changelog с версиями.
Кейс 02
Приложение-компаньон Ignis для диагностического прибора
в продеМобильное приложение-компаньон для физического диагностического прибора - подключаешься по коду, как к беспроводным наушникам, только вместо звука получаешь показания прибора в реальном времени.
Приватные ключи никогда не покидают защищённое хранилище телефона - так же, как банковское приложение прячет данные карты. На iPhone приложение ставится прямо из браузера, без App Store и платного аккаунта разработчика. Чтобы тестировать без физического прибора, написал его цифровой двойник - удалённые тестировщики подключаются к виртуальному прибору так же, как к настоящему.
- Свой эмулятор прибора - тестирование не привязано к железу
- Шифрование собственного протокола, не сторонняя готовая библиотека
- Установка на iPhone в три касания, без App Store
- Журнал решений и ошибок - тот же принцип, что и в ТвойCRM: видно, что и почему сделано, не только готовый результат
Как это устроено
Приложение на Flutter, приватные ключи в Keychain/Keystore. Протокол шифрования - на базе Ed25519/crypto_box, байт-совместимый Dart-порт PyNaCl, не готовая библиотека "из коробки".
Для тестирования без физического устройства написан отдельный эмулятор прибора и облачный WebSocket-мост на своём сервере. Логотип и бренд-система собраны в Figma, не нарисованы руками поверх кода.
Журнал решений и ошибок разбит на отдельные файлы по процессу, приложению, сборке, реверс-инжинирингу и безопасности, с автоматической проверкой на дубли номеров перед каждым коммитом.
Кейс 03
Аналитический дашборд для отдела продаж
в продеТот же движок, что несёт ТвойCRM (Кейс 01), только развёрнутый поверх системы клиента - amoCRM у него уже была. Проблема была не в CRM, а в статистике: часть лидов туда попадала, а дашборд с воронкой продаж их не видел. Почти половина лидов на графике значилась просто «Прочее» - деньги на рекламу тратились, а куда шёл каждый второй лид, никто не мог сказать.
Подключил amoCRM к дашборду по API - данные обновляются сами каждые 15 минут, без ручной выгрузки и экселя. Перед тем как включить обновление на боевых данных, сверил всё с реальными сделками клиента: выручка по факту лежала не там, где её ожидали найти. Без этой проверки каждая продажа в отчётах показывала бы ноль.
- Тот же проверенный движок, что и у ТвойCRM: модуль вырос на платформе, которая уже работает в проде
- Воронка стала полной - канал, который раньше вообще не считался, теперь виден в общей картине бюджет→выручка
- Ошибка с выручкой поймана до отчёта клиенту, а не после - иначе каждая продажа отображалась бы нулём
- Половина «потерянных» лидов теперь на виду - вместо одной цифры «Прочее» видно, откуда они реально пришли
- Готовая интеграция с amoCRM - для новой компании на той же CRM подключается быстро, а метрики и воронка каждый раз настраиваются под конкретный бизнес, не под шаблон
- Бюджет и продажи в одном месте - тем же способом ежедневно синкаются траты Google Ads и Яндекс.Директа, дашборд видит расход и выручку по каждому каналу
Как это устроено
Фундамент тот же, что у ТвойCRM: self-hosted n8n и Postgres/Supabase, один и тот же паттерн сервисных функций для записи данных. Синк с amoCRM подключается как ещё один источник данных к уже работающей платформе.
Данные забираются опросом каждые 15 минут, а не через подписку на события amoCRM - так надёжнее: если один тик пропущен, следующий подхватит те же данные, а задвоения не будет, потому что защита стоит на уровне базы данных, а не в логике скрипта.
Перед запуском все цифры сверялись с живыми сделками клиента, а не с описанием API. Так нашлась ошибка с полем выручки и выяснилось, что этапов воронки на деле почти вдвое больше, чем предполагалось изначально - решение по спорным статусам согласовали с клиентом, а не додумали сами.
Заодно навели порядок в источниках трафика: почти полсотни разных значений в CRM были размечены лишь частично, остальное тихо проваливалось в «Прочее». Точные совпадения поправили сразу, а сырое значение источника стали сохранять отдельно - чтобы новый, ещё не размеченный канал было видно в отчётах, а не терять его молча.
Следующий шаг, пока не реализованный: предиктивная аналитика - прогноз выручки по каналу на основе текущей динамики воронки, а не только факт за прошлый период.
Кейс 04
Три бота для одной онлайн-школы
в продеТри бота под одного клиента, разные задачи, общая архитектура: каждый готовит результат, а подтверждает его человек.
Личностные квиз-боты
Telegram-бот от лица персонажа - Мари, Карен, дальше по очереди. После короткого квиза о характере бот сразу передаёт менеджеру готовый разбор результатов - тот открывает диалог не с чистого листа, а уже зная, что предложить, и именно это поднимает конверсию, а не сам факт квиза. Конвейер: у каждого нового персонажа - готовый чек-лист по медиа и автоматическая проверка перед запуском, четвёртый бот собирается быстрее третьего.
Бот диагностики ученика
Ученик проходит тест по личной ссылке - уровень и вероятные пробелы считаются сами. Преподаватель открывает карточку ученика прямо в Пачке и по шагам заполняет разбор: сильные стороны, зону роста с примером с занятия, цель. На выходе - готовый брендированный отчёт и учебный план, сразу понятный и ученику, и родителю.
Бот учёта совещаний
Личный статус сотрудник надиктовывает голосом - бот сам раскладывает его по задачам в Яндекс Трекере и статьям в Яндекс Вики. С общим созвоном осторожнее: несколько голосов без разметки бот не берётся разносить с той же уверенностью, поэтому такие находки приходят карточками-кандидатами и ничего не создают в рабочих системах, пока их не подтвердит человек.
- Три бота, один принцип - подтверждение человеком перед любой записью в боевые системы
- Конвейер вместо разовой сборки - новый квиз-бот выходит на готовых чек-листах и проверках
- Python - отдельный стек под ботов, независимый от CRM-стека на Next.js и n8n
06
Рабочий стек
Список ниже - для тех, кому интересно заглянуть под капот. Разбираться в нём не нужно - выбор инструментов остаётся моей заботой, даже если стек заказчика устроен иначе. Нанимают за результат.
07
Расскажите о задаче
Если задача не мой профиль - скажу сразу, без недели вежливой переписки. Дизайн с нуля - честно, не моя сильная сторона. А вот готовую дизайн-систему или референсы возьму и доведу до рабочего интерфейса без потерь.
- Асинхронно - без обязательных созвонов по расписанию, пишу и отвечаю по мере готовности
- ТЗ - хоть голосовым в Telegram: наговорили мысль, я сам оформлю её в план
- План согласуем - и сразу в работу, без долгих раскачек
- Каждая правка видна сразу на превью-ссылке - не нужно ждать демо-звонка, чтобы понять, что происходит с вашим заказом
LEONARD BABAKOV - SOLO PRODUCT ENGINEER - VOLZHSKY, RU
Превью деплоится автоматически при каждом обновлении - уведомление в Telegram-бот подтверждено