От «работает у меня» к «работает у клиента»: первая внешняя установка AI-продукта
12 мая 2026 года я впервые поставил свой продукт другому человеку. До этого он жил только у меня и работал на мои виллы на Бали — около 16 активных объектов под управлением. Сегодня впервые вышел во внешний мир: к живому клиенту с его сервером, его данными, его конфигурацией. К человеку, который будет на этом работать, а не я.
Звучит как праздник. На деле первый день превратился в урок про то, как легко сесть не на тот поезд, даже когда точно знаешь, куда ехать. А второй — про то, что когда вокруг много автоматики, накопленная ошибка умеет жить очень долго и очень тихо.
Расскажу оба дня подробно — потому что каждый из них дал что-то, что изменит как я работаю дальше.
Почему переход от «работает у меня» к «работает у клиента» — отдельная задача
Прежде чем рассказывать про конкретные дни, важно объяснить кое-что общее. Многие думают, что если система работает у тебя, значит она готова к клиенту. Это не так. Это принципиально разные вещи.
Когда система работает у тебя, она адаптирована к твоему окружению: твоей операционной системе, твоим версиям библиотек, твоей файловой структуре, твоим привычкам в настройке. Ты никогда не замечаешь все эти неявные зависимости — они просто работают, потому что ты сам их и создал. Ты думаешь, что знаешь систему. На самом деле ты знаешь систему-в-своём-окружении.
Когда система приходит к клиенту, она встречает другое окружение. Другая версия Python. Другие права. Другая структура папок. Другой сервер с другой историей установок. И вот тогда вылезают все неявные зависимости, которые ты никогда не видел — потому что у тебя они просто были.
Хорошая новость: это решаемо. Решение называется установщик или пошаговая инструкция по развёртыванию. Плохая новость: большинство людей, которые автоматизируют свой бизнес, создают это решение только после первого клиента. Я не исключение.
И это не лень и не безответственность. Это рациональное поведение: пока продукт живёт только у тебя, тебе не нужен установщик. Ты и так знаешь как его запустить. Потребность в установщике возникает именно тогда, когда появляется первый внешний клиент. Поэтому у большинства он и появляется только после первого клиента — иногда дорогой ценой потерянного времени.
День первый: как я потерял рабочий день на неправильный подход
Утром получил от клиента всё необходимое: доступы к серверу, реквизиты, список требований. Задача выглядела ясной: поставить мою систему управления на его инфраструктуру, подключить к его источникам данных, проверить что всё работает.
И почему-то пошёл по сложному пути. Вместо того чтобы взять готовое, начал вручную переносить куски своей системы: копировал модуль за модулем, подгонял настройки под незнакомое окружение, разбирался с зависимостями в ручном режиме. Логика казалась разумной: «я знаю эту систему лучше любого установщика, я сделаю как надо». Но именно здесь и была ловушка.
К обеду — каша в голове и ничего рабочего на стороне клиента. Полез за очередным модулем и увидел: я переношу блок, который отвечает за совсем другую функцию. Не ту, что нужна этому конкретному клиенту. Просто шёл по коду в алфавитном порядке и забыл свериться с тем, что реально нужно сделать.
И тут пришло простое понимание. У меня же есть готовая упакованная версия продукта — специально написанная для установки у клиентов. Я делал её заранее, именно для этой ситуации. Просто прошёл мимо. Сел не на тот поезд, потому что не посмотрел на расписание. День в трубу.
Это называется «проблема эксперта»: когда знаешь систему досконально, начинаешь срезать углы и пропускаешь шаги, которые сам же написал для случаев когда всё надо делать правильно. Установщик существовал. Я им не воспользовался. Причина — импульс «я знаю как это работает, зачем мне скрипт». Это ловушка, в которую попадает каждый технический основатель при первом клиенте.
Что конкретно пошло не так
Когда переносишь систему вручную, каждый шаг требует принятия решений: что переносить, в каком порядке, как адаптировать под новое окружение. Ты переключаешься между контекстами — конфигурация, зависимости, логика, данные. После 3-4 часов такой работы принимать правильные решения становится труднее. Появляются «сделаю это потом» и «это наверное не нужно» — и в этот момент начинаешь переносить не то.
Готовый установщик решает эту проблему не потому что он умнее тебя. А потому что принимает решения заранее, в спокойном состоянии, а не в середине напряжённого дня. Скрипт не устаёт. Скрипт не пропускает шаги. Скрипт не переносит «не тот модуль». Это не про автоматизацию ради автоматизации — это про надёжность процесса в момент когда цена ошибки высокая.
День второй: готовый установщик и то, что он немедленно вскрыл
Утром начал сначала. Открыл упакованную версию, запустил установщик на машине клиента.
Он споткнулся — в нескольких местах. Я первый человек, который пускает его на чужой машине в реальных условиях. На новой почве вылезли дефекты, которых раньше не видел: другая версия библиотеки, несовместимая с тем, что ожидал скрипт; жёстко прописанный путь к файлу конфигурации, которого нет по этому адресу; нюанс с правами доступа к папке логов; переменная окружения, которую не вынес в .env потому что «у меня она всегда одна и та же».
Каждую проблему чинил по ходу и сразу делал две вещи: исправлял установщик и вписывал найденную проблему в инструкцию. Не «потом запомню» — сразу в документ. Потому что следующий клиент уже через неделю, и наступать на те же грабли я не хочу.
К обеду у клиента всё крутилось. Подключилось куда надо, ждёт работы. Первая внешняя установка моего продукта — состоялась.
Время: около 5 часов с учётом всей отладки и 4-5 дефектов по дороге. Следующий клиент пройдёт этот же путь вдвое быстрее — все найденные дефекты уже закрыты, инструкция дополнена конкретными пунктами с точными причинами каждой проблемы.
Что нужно подготовить до первого внешнего клиента
Пока ставил установщик и чинил дефекты, отмечал для себя вещи, которые стоило сделать раньше. Вот честный список без приукрашиваний.
Упакованная версия обязательна до продажи, не после. Если у вас нет установщика или детальной пошаговой инструкции — вы продаёте не продукт, а услугу по установке. Это разные экономики: продукт масштабируется без линейного роста вашего времени, услуга — нет. Пока продукт живёт только у вас, это незаметно. Первый внешний клиент это вскрывает немедленно.
Тест на «чужой машине» нужно пройти хотя бы раз до первого клиента. Возьмите чистый VPS, создайте окружение с нуля, запустите установщик. Вылезет ровно то, что вылезет у реального клиента — лучше это будет стоить вам 2 часа, а не полдня в момент когда клиент ждёт результата. Это не сложно технически, но требует дисциплины: нужно намеренно сделать это до появления клиента, а не после.
Документируйте дефекты в момент обнаружения. Каждая проблема, найденная по ходу — это будущий пункт FAQ или шаг в инструкции. Если записывать по памяти через день, детали теряются. «Что-то с правами» — бесполезно. «Папка /var/log/myapp должна иметь права 755 и принадлежать пользователю, под которым запускается сервис» — полезно. Лучший момент для документирования — сразу после фикса, пока помнишь точную причину.
Первый клиент всегда дороже второго по вашему времени. Это нормально. Первый вскрывает все скрытые проблемы. Второй проходит по уже исправленному пути. Третий — ещё быстрее. Если понимать это заранее, не будет ощущения что «всё сломалось» — просто идёт обкатка на реальных условиях.
Чек-лист «что проверить перед сдачей». Он должен быть написан до встречи с клиентом. После развёртывания по этому списку вы подтверждаете: система работает, данные идут, логи чистые, нет ошибок в первые 15 минут после запуска. Без списка проверяешь «по ощущению», а ощущение после 5 часов отладки — ненадёжный инструмент.
Вторая половина дня: год неверного учёта
После того как у клиента всё заработало, сел считать прибыль одной из своих вилл за первый квартал. Рутинная задача, которую периодически делаю руками — чтобы сверить с тем, что показывает система.
Открываю формулу расчёта доходности и вижу: она не учитывает налоги и маркетинговые расходы. В таблице транзакций эти статьи есть. В детальных отчётах по каждой транзакции — есть. А в сводной формуле расчёта доходности по вилле — нет. Получается, весь год я смотрел на доходность с двумя пропущенными статьями расходов.
Как такое происходит: формула добавлялась постепенно, по мере того как я добавлял категории расходов в систему. Налоги и маркетинг появились позже основных статей. Формулу не обновил — просто начал использовать, потому что она давала числа и числа выглядели разумными. Ничто не указывало на то, что что-то пропущено.
Цифры там не переворачивают картину. Но они достаточно значимы, чтобы принять неверное решение о том, насколько конкретная вилла прибыльна относительно других объектов в портфеле. И хуже всего — я не знал, что смотрю на неполную картину. Всё выглядело корректно. Это и есть самый опасный тип ошибки: не та, что бросается в глаза, а та, что выглядит как норма.
Ошибка в тысячу раз: когда цифры есть, но они неверные
Пока разбирался с формулой доходности, наткнулся на вторую дыру по той же вилле. Часть расходов на ремонт была внесена с ошибкой в 1000 раз. В системе хранились цифры в миллиардах рупий — там, где должны быть миллионы.
Как это обычно происходит: кто-то вводит данные вручную, путается в единицах, и вместо 500 000 рупий вводит 500 000 000. Система принимает число без вопросов — валидации на «разумность» суммы не было. Визуально в интерфейсе ничего не бросается в глаза, если не знаешь ожидаемый диапазон для этого типа расходов. Просто большое число в строке, и строк таких много.
Поправил запись, пересчитал P&L за затронутый период, сверил итоговый баланс с инвестором по этой вилле. Полтора часа работы. Хорошая новость: ошибка жила в аналитическом слое, а не в расчётах выплат инвесторам. Плохая: я узнал об этом случайно, не потому что система меня предупредила. Если бы не сел считать руками в этот конкретный день — неизвестно когда бы обнаружил. Может, через год. Может, при споре с инвестором о цифрах.
Автоматизация накапливает ошибки молча — и это системная особенность
Если смотреть на оба дня целиком, есть одна сквозная идея: когда вокруг много автоматики, накопленная ошибка умеет жить очень долго и никого не беспокоить. Вот конкретные примеры только из последних недель работы с моей же инфраструктурой.
Поллер входящих сообщений в Instagram тихо молчал 22 дня — система запускалась по расписанию, логировала успешный запуск, но не получала ни одного реального сообщения. Когда зашёл разбираться, обнаружил 304 непрочитанных сообщения. Подробнее об этом — в статье про 304 потерянных лида.
WhatsApp бот-переводчик от моего же номера отвечал партнёру по переговорам текстом, противоречащим тому, что писал я — 6 недель. Контрагент видел: один номер, два разных сообщения. Я не знал, потому что бот работал «в фоне» и технически не ошибался.
Все три ситуации — не про то, что автоматизация плохая. Она работала. Делала своё дело. Но в каждом случае не было механизма, который поднял бы флаг: «здесь что-то не так». Скорость движения растёт. Скорость обнаружения ошибок — нет. Это системная особенность, а не баг конкретного инструмента.
Как встроить ревизии в систему, а не делать их по случаю
Главный вывод после двух дней: ревизии должны быть частью системы, а не реакцией на случайно найденную проблему. Вот что я сейчас встраиваю в свой ритм.
Финансовая сверка руками — раз в месяц по одному объекту. Взять одну вилла из портфеля, открыть транзакции за месяц, посчитать P&L вручную и сравнить с тем, что показывает система. Это занимает 1-2 часа и ловит методологические ошибки до того, как они накопятся за год. Если цифры совпадают — отлично, уверенность растёт. Если расходятся — вы нашли проблему раньше, чем она стала критичной.
Проверка «живых» сервисов — раз в две недели. Зайти в каждый активный бот и посмотреть: что он делал последние 14 дней? Есть ли аномалии в данных? Есть ли нули там, где должны быть числа? Это не технический мониторинг с алертами — это «взгляд хозяина». Автоматический монитор может не знать, что ноль — это аномалия для конкретного контекста. Хозяин знает.
Валидация диапазонов при вводе данных. Если в бизнесе средний чек операции — миллион рупий, система должна спрашивать подтверждение при вводе числа выше 10 миллионов. Простая техническая мера, которая поймала бы ошибку в 1000 раз до попадания в базу. Таких «защитных сеток» при ручном вводе данных должно быть много.
Тест установщика перед каждым новым клиентом. Не «установщик работал в прошлый раз», а «запустим на тестовом окружении прямо сейчас». Это 30-60 минут, которые могут сэкономить полдня у клиента. После каждого нового клиента установщик обновляется — значит перед следующим его надо тестировать снова.
Ни одна из этих вещей не требует найма. Они требуют дисциплины — поставить в календарь и сделать, а не делать только когда что-то видимо сломается. Это и есть разница между системой, которая масштабируется, и системой, которая масштабируется до первой проблемы.
Два типа AI-автоматизации: для себя и для клиентов
Когда я строил свою инфраструктуру управления виллами, я строил её для себя. Это означало: я могу позволить себе знать все неявные зависимости, помнить где что лежит, исправлять ошибки по мере их возникновения. Система была личным инструментом, и как любой личный инструмент — она требовала знания хозяина для нормальной работы.
Когда появляется первый клиент, система должна работать без хозяина. Это другое требование. Клиент не знает, где лежат конфигурационные файлы. Не знает, какие переменные окружения надо установить. Не знает, что при ошибке X надо делать Y, а не Z. Это знание было у меня в голове, а не в документации.
Разница между «системой для себя» и «системой для клиентов» — это разница между инструментом и продуктом. Инструмент требует опытного пользователя. Продукт работает у широкого круга пользователей с минимальным вмешательством автора. Превратить инструмент в продукт — отдельная работа, которую не видно снаружи, но которая критична для масштабирования.
Конкретно это означает: документация развёртывания, которую может выполнить человек без знания вашего кода. Установщик, который обрабатывает типичные различия в окружении. Чёткие сообщения об ошибках, которые указывают на причину, а не просто выдают стектрейс. Чек-лист для проверки успешности установки. Это не объём работы на неделю — это объём работы на 2-3 дня. Но его нужно сделать.
Ещё один важный момент: когда продукт стоит у клиента, вы не можете «просто зайти и посмотреть» как у себя. Любая ошибка требует либо удалённого доступа, либо понятного лога, который клиент может передать вам. Значит, логирование тоже должно быть рассчитано на стороннего читателя — конкретные сообщения, конкретные уровни важности, никаких «что-то пошло не так» без деталей.
Это то, что я начал систематизировать после первой внешней установки. Не потому что это сложно технически, а потому что без этого следующий клиент займёт столько же времени, сколько первый. А цель — чтобы третий клиент занял вдвое меньше времени, чем второй.
Итог: что поменяется в работе
Первый внешний клиент развёрнут. Несколько дефектов установщика закрыты и задокументированы. Год неверного учёта по одной вилле исправлен. Ошибка в данных на 1000 раз — найдена и поправлена.
За два дня один человек с автоматикой сделал то, что у команды без неё заняло бы неделю. Развёртывание у клиента, аудит финансов, правка данных и документирование — всё параллельно, без совещаний и без «уточни у того-то». Именно так работает бизнес без офисных сотрудников, когда инфраструктура выстроена правильно.
Но главный итог не в скорости. Главный итог в понимании: автоматизация меняет соотношение скорость/ошибки. Ты двигаешься быстрее — и ошибки тоже накапливаются быстрее, потому что каждый инструмент делает своё дело без вопросов. Ревизии — это не признак слабости системы. Это часть системы.
Тихо сидит ошибка в формуле. Тихо живёт в данных. Тихо молчит поллер. Ты на это опираешься, принимаешь решения. А однажды садишься руками проверить — и видишь дыру в год шириной. Теперь надо чаще нырять руками. Не потому что не доверяю своим системам, а чтобы такие дыры не копились молча.
О том, как строить систему, которая сама сообщает о поломках раньше, чем вы их найдёте случайно — читайте в статье про тихие поломки автоматизации. Там конкретные механизмы раннего обнаружения, которые я использую сейчас.