Отчет Retool: 78% планируют создать пользовательские инструменты к 2026 году
При поддержке Retool
Раньше логика была простой: покупать готовое ПО для большинства задач дешевле, быстрее и безопаснее. Самостоятельная разработка оставалась уделом компаний с крупными инженерными командами, большими бюджетами и настолько специфическими проблемами, которые не мог решить ни один вендор. Но теперь стоимость написания программного кода упала до нуля.
Сегодня создавать собственное ПО может каждый, однако корпоративные модели и модели управления пока за этим не успевают. В отчете Retool за 2026 год об изменениях в выборе между собственной разработкой и покупкой (Build vs. Buy Shift Report), основанном на опросе 817 разработчиков, подробно прослеживается то, как именно происходит этот сдвиг.
Кривая затрат изменилась, а цены на SaaS — нет
Два года назад создание кастомного внутреннего инструмента могло занять у команды инженеров недели или месяцы и обойтись в шестизначную сумму. Сегодня руководитель операционного отдела с подходящей платформой может получить рабочий прототип за день-два. Этот структурный сдвиг обусловлен разработкой с помощью ИИ и созреванием платформ для создания корпоративных приложений.
Между тем цены на SaaS не изменились: по-прежнему взимается плата за каждого пользователя (per-seat) за универсальное программное обеспечение, которое помимо этого требует затрат на кастомизацию и интеграцию. Когда стоимость разработки падает на порядок, а стоимость покупки остается прежней, экономика меняется для каждой компании, а не только для тех, у которых есть крупные инженерные команды.
Данные это подтверждают. Отчет Retool показал, что 35% команд уже заменили хотя бы один SaaS-инструмент собственной разработкой, а 78% планируют создать больше кастомных инструментов в 2026 году.
Автоматизация рабочих процессов и административные инструменты находятся в зоне риска для SaaS
Этот сдвиг происходит неравномерно. В число основных SaaS-инструментов, которые респонденты заменили или планируют заменить, входят средства автоматизации рабочих процессов (35%) и внутренние инструменты администрирования (33%), за которыми следуют BI-инструменты (29%) и CRM (25%).
Приобретенный инструмент автоматизации рабочих процессов должен обслуживать тысячи клиентов, поэтому он оптимизируется под средний случай — а средний случай на самом деле ни у кого не является реальным. Внутренние рабочие процессы у каждой компании свои. Они отражают организационную структуру, требования к комплаенсу, системы данных и бизнес-логику, уникальные для конкретной организации.
Внутренние административные инструменты несут в себе ту же проблему: они по определению специфичны для компании. Эти категории всегда хуже всего подходили для коробочного программного обеспечения, и теперь появилась доступная альтернатива (в отчете Массачусетского технологического института «Состояние ИИ в бизнесе» (State of AI in Business) сообщалось об экономии от 2 до 10 млн долларов ежегодно на задачах обслуживания клиентов и обработки документов).
Модель замены, как правило, носит дополняющий, а не радикальный характер (никто просто так не выбрасывает Salesforce). Компании заменяют конкретные элементы, которые никогда до конца не подходили: процесс согласования, требовавший трех обходных путей, дальновидную панель управления, которая не могла подключиться к реальным данным… но эти точечные замены накапливаются. Как только команда создает один инструмент, который работает лучше купленного, стандартный вопрос меняется с «Что нам купить?» на «Можем ли мы это создать?»
Разработчики обходят IT-отдел, что указывает на масштабные проблемы с закупками
Самое очевидное доказательство того, что процессы закупок не поспевают за возможностями разработки, — это масштабы теневого IT (shadow IT), возникающего сегодня внутри предприятий. Отчет Retool показал, что 60% создателей ПО за последний год создавали инструменты, рабочие процессы или средства автоматизации в обход IT-отдела, а 25% заявляют, что делают это регулярно.
Даже опытные и рассудительные специалисты выбирают скорость вместо следования процессам. Две трети всех респондентов опроса (64%) занимают должности старших менеджеров и выше. Существующие циклы закупок не были рассчитаны на мир, в котором создание программного обеспечения занимает дни, а не месяцы. Когда люди любят цитировать данные о 95-процентном провале пилотных проектов генеративного ИИ, они не учитывают мощное массовое внедрение технологий прямо под носом у руководства.
Теневое IT в таких масштабах — это сигнал о спросе. Люди, ближе всех стоящие к проблемам, говорят организациям, что существующий процесс не успевает за потребностями: 31% тех, кто действует в обход IT, делают это просто потому, что могут создать решение быстрее, чем IT-отдел предоставит инструменты. Поэтому попытки подавить эту инициативу непродуктивны. Проблема в том, что инструменты, создаваемые в тени, с наибольшей вероятностью застрят, прежде чем станут полезными.
Прототип на базе вайб-кодинга (vibe-coded), работающий на тестовых данных, впечатляет. Производственный инструмент, подключенный к вашей реальной системе Salesforce, с ролевым доступом и проверкой безопасности — это полезно. Отчет показал, что 51% разработчиков выпустили промышленное ПО, которое в настоящее время используется их командами, и примерно половина из них сообщает об экономии шести и более часов в неделю.
Когда разработка ведется в неуправляемой среде, организации не получают стабильно ни того, ни другого. Кто-то подключает инструмент на базе ИИ к рабочим данным без журнала аудита, средств контроля доступа и ответственного лица. Умножьте это на десятки разработчиков по всей организации, и вы получите расширяющуюся зону уязвимости, о существовании которой IT-отдел даже не подозревает.[1]
Команды, чьи решения собственной разработки доходят до стадии производства, обычно обладают тремя вещами, которых нет у других: подключением к реальным источникам данных, моделью безопасности и прав, которой они доверяют, и процессом проверки того, что именно развертывается. Направление энергии разработчиков в управляемую среду, где скорость и безопасность не противоречат друг другу, — это способ предотвратить превращение теневого IT в угрозу.
Управление станет определяющим фактором для следующей эры SaaS
Переход от покупки к самостоятельной разработке уже идет полным ходом. Более важный вопрос теперь заключается в том, кто контролирует среду, в которой эта разработка происходит.
Неуправляемое создание ПО влечет за собой риски безопасности и затрудняет оценку окупаемости инвестиций (ROI). Невозможно измерить сэкономленное время с помощью инструментов, о существовании которых IT-отдел не знает или которые используются только в рабочем процессе одного конкретного сотрудника. Нельзя обеспечить контроль доступа к прототипу, который кто-то подключил к производственным данным в прошлый вторник. И это не гипотетические риски: в опросе Deloitte за 2026 год «Состояние искусственного интеллекта на предприятии» (State of AI in the Enterprise), охватившем более 3200 лидеров, конфиденциальность и безопасность данных заняли первое место среди опасений по поводу ИИ (73%), а возможности управления расположились следом с 46%. Организациям, у которых в 35% случаев отсутствуют метрики производительности ИИ, не хватает не просто панели мониторинга. Им не хватает инфраструктуры подотчетности, которая вообще оправдывает разработку вместо покупки.
Те организации, которые рассматривают управляемую среду как обязательное условие для масштабной разработки, смогут на деле доказать ее эффективность. Остальные узнают об этом тогда, когда что-нибудь сломается.
Чтобы подробнее ознакомиться с данными, в том числе с тем, как предприятия подходят к разработке с помощью ИИ, читайте полную версию отчета за 2026 год об изменениях в выборе между собственной разработкой и покупкой (2026 Build vs. Buy Shift Report).
[1] Цена этого может оказаться высокой: отчет IBM о стоимости утечки данных за 2025 год (Cost of Data Breach Report) показал, что инциденты, связанные с ИИ, обходятся организациям более чем в 650 000 долларов каждый.
Дэвид Хсу (David Hsu) — генеральный директор Retool.
Спонсорские статьи — это контент, подготовленный компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко маркируются. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.
