Где заканчивается внедрение и начинается собственный продукт

Привет, я — Антон Фокин, CEO Qtim. Рынок предлагает все больше готовых решений: коробки, платформы, конструкторы, отраслевые системы. Для бизнеса это выглядит удобно. Запуск быстрее, входной чек ниже, техническая команда меньше. Такая модель долго казалась самым разумным способом цифровизации.

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

Что считать традиционным запуском

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

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

Скрытые издержки «дешевого» внедрения

На старте реализация почти всегда выглядит дешевле собственной разработки. Основной счет приходит позже.

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

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

Третья издержка — зависимость от поставщика. Если ключевые данные, правила и ограничения живут внутри чужой платформы, уйти с нее без потерь уже почти невозможно. Это жесткая привязка к вендору. Компания вроде бы управляет сервисом, но критические условия его жизни определяет не она.

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

На этом месте новость про ФНС становится уже не внешним сюжетом, а прикладной проблемой. Если компания заявляет собственный ИТ-продукт, а ключевая логика, права на код и критические сценарии размазаны между коробкой, подрядчиком и ручными операциями, доказывать самостоятельность такого решения становится намного сложнее.

Когда разработка с нуля честнее и выгоднее

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

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

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

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

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

Что делать на практике

Речь не о том, что коробочные решения плохи, а разработка с нуля всегда лучше. Просто эти подходы решают разные задачи, и смешивать их не стоит. Если бизнес уже чувствует, что готовая база стала тормозить развитие, сначала полезно разложить систему по слоям. Нужно понимать, что можно оставить на внешней стороне, а что относится к критической логике продукта. Именно в этой точке и начинается зависимость, которая влияет на экономику, скорость и управляемость.

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

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