Почему дешевые обходные схемы становятся дорогими

Привет, я — Антон Фокин, CEO Qtim. Долгое время обходной путь выглядел разумной экономией. Быстро собрать минимальную конструкцию ради статуса ИТ-компании, льгот или ускоренного запуска, не лезть сразу в создание собственной технологической базы, закрыть недостающее внешними сервисами и ручными операциями, а дорогие вопросы отложить на потом. На старте это действительно снижает затраты. Денег нужно меньше, команда компактнее, путь до выручки быстрее. В этом и ловушка: экономия видна сразу, стоимость ошибки приходит с задержкой. Например, сейчас, ведь ФНС собирается оценивать разработки ИТ-компаний.

Почему короткий путь казался разумным

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

Проблема появляется позже. Временная схема редко остается таковой. Она обрастает клиентами, деньгами, новыми требованиями и внутренними привычками. В какой-то момент бизнес уже не может быстро отказаться от нее, хотя именно она начинает тормозить развитие.

Что меняется сейчас

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

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

Во что выливается мнимая экономия

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

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

Почему срочная пересборка всегда дороже

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

Когда обходная схема начинает определять маржу, сроки изменений, устойчивость льготы и силу переговорной позиции, это перестает быть вопросом разработки. Это ошибка в экономике решения. Бизнесу кажется, что он сэкономил на входе. На деле просто перенес расход в будущее и сделал его намного неприятнее.

Именно поэтому тема касается не только статуса ИТ-компании. Она — о зрелости бизнеса вообще. Если компания не контролирует критическую логику продукта, она хуже управляет собственной скоростью и защищает свою ценность. А еще в любой сложный момент платит дороже, чем планировала.

Что делать, если компания уже сидит на такой конструкции

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

Если у вас сейчас что-то похожее, пишите. Возможно, сэкономлю вам пару неправильных решений.