$37,5 млн за пять лет и около 60 человек в штате — в такую сумму может вылиться собственная внутренняя платформа для разработки, если компания решит собирать ее сама, а не покупать готовый стек. Об этом сообщает The New Stack в разборе экономики platform engineering, и для русскоязычных IT-команд это полезный холодный душ: идея «сейчас быстро соберем свою IDP на open source» почти всегда звучит дешевле, чем потом выглядит в бюджете.
Автор материала Майкл Коте пишет не о красивой схеме на доске, а о полной стоимости владения внутренней платформой. Базовая оценка звучит жестко: около $7,5 млн в год, если делать все «по-взрослому», то есть не ограничиваться набором тулзов, а строить полноценный внутренний продукт для разработчиков. За пять лет получается $37,5 млн. И главный тезис здесь не в том, что platform engineering не нужен, а в том, что многие компании считают только цену старта и почти не считают цену постоянной эксплуатации.
Это болезненное место всей темы IDP. Когда команда говорит «мы сами соберем платформу», обычно в голове у всех один и тот же набор слов: Kubernetes, шаблоны, CI/CD, каталог сервисов, self-service, политики безопасности. На бумаге выглядит как конструктор из знакомых компонентов. На практике внутренняя платформа быстро превращается в отдельный продукт со своей дорожной картой, поддержкой, требованиями к надежности и вечным списком «это тоже надо бы автоматизировать». И вот тут начинается математика, от которой энтузиазм обычно становится заметно тише.
Коте отдельно подчеркивает: платформы плохо продаются внутри компании через прямой ROI, потому что они не приносят деньги сами по себе. Они не продают подписки, не закрывают сделки и не растят выручку напрямую. Их эффект косвенный: меньше ручной работы, меньше toil, быстрее поставка, ниже операционный хаос, лучше безопасность и предсказуемее эксплуатация. Звучит разумно, но для директора, который открывает Excel, это не всегда ответ. Поэтому разговор почти неизбежно смещается из «сколько это стоит» в «какую проблему мы на самом деле снимаем и сколько нам сейчас обходится бардак без платформы».
В этом смысле материал The New Stack хорошо попадает в нерв 2026 года. На фоне AI-инструментов и ускорившейся генерации кода компании получают не только больше возможностей, но и больше сервисов, пайплайнов, окружений и эксплуатационных обязанностей. Код писать стало проще, а вот поддерживать все это хозяйство в живом состоянии легче не стало. Поэтому спрос на platform engineering растет, но вместе с ним растет и соблазн сыграть в DIY: взять open source, добавить пару сильных инженеров и объявить, что теперь у нас своя внутренняя платформа. Проблема в том, что open source убирает только часть лицензионного чека. Люди, интеграция, сопровождение и эволюция платформы никуда не исчезают.
Отсюда и неудобный вывод для CTO, VP Engineering и платформенных команд. Если компания действительно хочет строить внутреннюю платформу сама, ей надо защищать не проект на полгода, а многолетнее обязательство. Не «поднимем портал для разработчиков», а финансируем отдельный слой инфраструктурного продукта на годы вперед. Причем с понятным владельцем, командой, метриками внедрения и правом говорить «нет» зоопарку кастомных исключений. Иначе вместо платформы как продукта получится еще одна инженерная стройка, которая живет на героизме нескольких людей и плохо переживает их отпуск.
Для разработчиков эта история тоже довольно приземленная. Внутренняя платформа хороша не потому, что она модная, а потому что снимает лишнюю когнитивную нагрузку: не нужно каждый раз собирать пайплайн с нуля, спорить о базовых паттернах доставки, вручную проталкивать инфраструктурные изменения и искать, кто вообще владеет сервисом. Но если платформа собирается по принципу «сделаем свою, потому что можем», разработчики часто получают не paved road, а еще один уровень абстракции с неочевидными правилами, задержками и внутренней бюрократией. То есть ровно то, от чего platform engineering вроде бы должен спасать.
Для бизнеса сигнал еще проще. Собственная внутренняя платформа может быть оправдана в очень крупных организациях, где требования к безопасности, совместимости, масштабу и внутренним процессам действительно отличаются от рынка. Но даже там вопрос уже не в том, можно ли это собрать, а в том, готовы ли вы платить за это каждый год и не притворяться, что дальше платформа будет жить сама. В противном случае «сэкономили на покупке» легко превращается в дорогую форму самообмана, особенно когда через пару лет выясняется, что платформа все еще не закончена, а команда уже просит следующий бюджет.
Самый неприятный вопрос после такого разбора звучит не «строить или не строить», а «что именно компания считает своей компетенцией». Если конкурентное преимущество бизнеса в продуктах, данных и скорости запуска новых сервисов, то внутренняя платформа должна помогать этим вещам, а не становиться еще одним большим продуктом ради самого факта инженерной самостоятельности.