Когда «бутиковость» превращается в зависимость
В последнее время я встречаюсь уже не с первым проектом, где собственная или кастомно разработанная платформа для клиента становится не активом, а спорной и высокорисковой точкой в экономике компании.
На бумаге всё выглядит красиво.
- Есть уникальная платформа.
- Есть подрядчик или команда, которая её разработала.
- Есть поддержка.
- Есть ощущение «у нас всё своё, гибкое, бутиковое, под нас».
Но дьявол, как обычно, кроется в деталях — особенно когда наступают неудобные моменты.
Как банальный пример: когда бизнесу нужно быстро внести изменения, от которых зависит маркетинг, аналитика, продажи, запуск нового продукта или корректная работа воронки. Время ограниченное, никто не будет ждать квартал, пока внесут эти правки.
И вот здесь внезапно оказывается, что «бутиковость» превращается в зависимость.
Важный дисклеймер
Я ни в коем случае не обесцениваю работу разработчиков, архитекторов, DevOps, аналитиков и всех специалистов, которые строят сложные системы.
Я сам уже год строю продукт и прекрасно понимаю, каких титанических усилий стоит нормальная архитектура, инфраструктура, интеграции, поддержка, тестирование, исправление багов и постоянное улучшение продукта.
- Разработка — это сложно.
- Разработка — это дорого.
- Разработка требует времени.
- И не каждая «простая кнопка» действительно простая, если под ней легаси, зависимости, риски регрессии, отсутствие тестов и кривой старый код.
Это чистая правда.
Но есть и другая тоже правда.
Удобная модель монетизации зависимости
В своё время часть подрядчиков выбрала очень удобную модель — сначала сделать платформу, посадить на неё клиента, а потом монетизировать почти каждое движение вокруг этой платформы. И не просто монетизировать, а выставлять абсолютно нерыночный коэффициент, просто потому что «а что вы нам сделаете? уйдёте? это дороже».
Любой чих, правку, интеграцию, событие, кнопку, любой вебхук оценивают как «доп. коврики в автосалоне».
И проблема даже не в том, что за работу нужно платить. Конечно, нужно — никто бесплатно ничего делать не будет и все хотят зарабатывать. Проблема в отсутствии прозрачности, скорости, ответственности, нормальной коммуникации и неоправданно завышенных сроках реализации, отталкиваясь от которых строится цена.
Ты заходишь в проект, чтобы настроить сквозную аналитику, ставишь, казалось бы, простую задачу: «отправлять определённые события в нужный вебхук, добавить пару параметров, поправить логику передачи данных».
Задача может быть действительно простой, никто не просит построить самолёт и внедрить аналитические блоки внутрь платформы. Но со стороны команды, которая поддерживает платформу, внезапно прилетает оценка в 30+ часов, стоимость как за крыло того самого самолёта и ощущение, что эту задачу не хотят делать вообще, саботируя.
Не объясняют архитектурные риски, не показывают, где сложность, не предлагают альтернативы, не дают понятный план, не озвучивают сроки.
Просто «это долго, дорого, сложно, ждите».
Когда платформа тормозит весь бизнес
В другом проекте похожая ситуация. Ты как человек, который внедрился в маркетинг и аналитику, просишь закрыть несколько правок, от которых зависит движение всего маркетинга. А за маркетингом стоят продажи. За продажами — деньги. За деньгами — команда, обязательства, зарплаты, развитие продукта и собственно обеспечение тех, кто поддерживает платформу.
Но правки делаются не неделю, не две, а месяцами. И в какой-то момент бизнесу приходится не просто ждать, а перестраивать процессы вокруг того, что его собственная платформа не может быстро адаптироваться. И это очень странный движ.
Появляются костыли, альтернативные решения, ручные обходы, параллельный сбор данных, временные заплатки и привлечение к решению поставленной задачи сторонних людей.
В итоге копятся новые бизнес-процессы, которые нужны только потому, что старая, собственная система забуксовала.
Это опасный сигнал.
Бизнес не должен разворачивать всё своё движение только из-за того, что команда поддержки не может или не хочет работать с нормальной скоростью. Особенно если эта команда получает ежемесячную оплату за сопровождение.
Рынок изменился
В 2010-е можно было годами сидеть на самописной системе, где любая правка зависела от одного человека, который «знает, как там всё устроено».
Сегодня рынок другой, конкуренция выше, инструментов больше, скорость выше. Не говоря уже о том, что AI ускоряет разработку, прототипирование, аналитику, документацию.
Маркетинг быстрее тестирует гипотезы, продукты быстрее меняются и адаптируются к рынку и его условиям, особенно в шторм.
И если ваша бизнес-критичная система не может поменять кнопку, отдать событие, исправить очевидный баг или добавить простую интеграцию в адекватные сроки — это уже не «бутиковость», а самый настоящий операционный риск кастомной разработки, который может стать спусковым крючком к кассовому разрыву, если от этого зависит работа всей команды.
И в такой ситуации фаундеру очень сложно спорить, особенно в критические моменты. Потому что на другой стороне — техническая экспертиза, а у него часто нет возможности быстро проверить, действительно задача стоит 30 часов или её просто саботируют.
И именно на этой ситуации очень удобно зарабатывать, если у подрядчика есть желание не строить долгосрочные отношения, а выжимать максимум из зависимости клиента.
Но тут важно понимать, что бизнес — это не овечка, которую можно один раз побрить и пойти дальше.
Сейчас информация очень быстро ходит от фаундера к фаундеру. Нас же спрашивают о рекомендациях. Рынок хоть и широкий, но в контактах фаундеров все находятся «через рукопожатие».
Рекомендации работают хорошо. А антирекомендации работают намного быстрее для принятия решения — с кем работать, а с кем нет.
И если команда годами ведёт себя так, что бизнес чувствует себя заложником собственной платформы, рано или поздно это станет её репутацией.
Так кастомная разработка — это плохо?
Наоборот, часто это огромное конкурентное преимущество.
Но только если она остаётся инструментом бизнеса, а не превращается в точку зависимости, где каждое движение стоит дорого, долго и болезненно — с риском принятия очень неудобных и экстренных решений.
Бутиковость хороша тогда, когда она даёт гибкость.
Но если под видом бутиковости бизнес получает медленную поддержку, непрозрачные оценки, отсутствие документации и страх что-либо менять — это уже не бутиковость. Это заложничество, которое рано или поздно начнёт бить по экономике компании.