1. Почему «вас обокрали» не всегда значит «нарушили закон»
Слово «обокрали» здесь намеренно жесткое, но смысл тоньше. В большинстве проблемных проектов клиент не сталкивается с прямым мошенничеством. Он сам подписывает правила игры, где почти вся неопределенность оплачивается за его счет.
Подрядчик может действовать формально корректно: выставлять часы, принимать правки, переносить сроки, добавлять интеграции, просить оплатить поддержку, не передавать код до финального расчета. Проблема в том, что для бизнеса это все равно выглядит как слив бюджета: деньги ушли, а управляемого результата нет.
Поэтому главный вопрос не «плохой ли разработчик». Главный вопрос: есть ли в проекте система, которая ограничивает неопределенность до того, как она стала счетом. Если системы нет, перерасход почти неизбежен. И он будет законным.
Практичный тест: если перед оплатой этапа вы не можете показать демо, список закрытых задач, критерии приемки, доступ к репозиторию и прогноз допрасходов, вы платите не за результат. Вы платите за обещание.
2. Насколько проблема реальна: что говорят исследования и рынок
Перерасход в IT не редкая аномалия. В исследовании McKinsey и Oxford по крупным IT-проектам, опубликованном 1 октября 2012 года, проекты в среднем уходили на 45% сверх бюджета, на 7% сверх срока и давали на 56% меньше ожидаемой ценности. Это старое исследование, но оно до сих пор полезно как базовая статистика: софт опасен не только ценой, а разницей между обещанной и полученной ценностью.
Другой слой — качество. CISQ в отчете от 6 декабря 2022 года оценивал стоимость плохого качества ПО в США минимум в $2.41 трлн, а накопленный технический долг — примерно в $1.52 трлн. Это модельная оценка и не прямой счет вашему проекту. Но она хорошо показывает масштаб: баги, переделки, простои и поддержка старых решений — это отдельная экономика, а не мелкая техническая неприятность.
В 2026 году к этому добавились более динамичные расходы: облако, API, AI-сервисы, подписки и платформенные комиссии. Flexera 18 марта 2026 года сообщила: 85% опрошенных специалистов, принимающих решения по облаку, называют управление облачными расходами одной из главных задач, 17% превысили бюджет публичного облака за прошлый год, а оцененная доля неэффективных расходов на IaaS/PaaS выросла до 29%. Здесь никто может не «воровать» деньги. Архитектура просто разрешает счету расти быстрее, чем бизнес успевает его понимать.
3. Девять законных схем, через которые бюджет утекает
Ниже — не список «как подрядчики обманывают». Это карта зон, где клиент чаще всего теряет контроль. Каждая схема может быть нормальной рабочей практикой, если она ограничена договором, артефактами и приемкой. И каждая становится дорогой, если остается на словах.
1. Размытое ТЗ: вы покупаете не продукт, а бесконечную трактовку
Фраза «сделать личный кабинет», «интегрировать CRM», «разработать приложение под ключ» звучит понятно только до старта. После старта выясняется, что у кабинета есть роли, статусы, уведомления, документы, ошибки, права доступа, админка, журнал действий и десятки мелких состояний.
Если эти состояния не описаны, подрядчик почти всегда имеет формальный аргумент: «этого не было в объеме работ». Клиент почти всегда имеет эмоциональный аргумент: «но это же очевидно». Побеждает обычно договор, а не эмоция.
2. Оценка без границ: сумма есть, а допущений нет
Опасная смета выглядит красиво: этапы, часы, ставка, итог. Но если в ней нет допущений, исключений и условий пересмотра, она не управляет риском. Она просто создает иллюзию контроля.
В нормальной оценке должно быть видно, что включено, что не включено, какие интеграции считаются типовыми, сколько раундов правок входит в стоимость, какие данные предоставляет клиент и где цена может измениться. Иначе любая неясность становится платной.
3. Почасовая модель без потолка: часы идут, ценность не обязана расти
Почасовая модель сама по себе не зло. Она нужна, когда объем нельзя надежно оценить заранее. В американском FAR 16.601 прямо сказано: модель time-and-materials применяется, когда невозможно точно оценить объем, длительность или стоимость, и такая модель не дает подрядчику позитивного стимула контролировать стоимость или эффективность труда. Источник про госзакупки США, но экономическая логика универсальна.
Поэтому почасовая модель без недельного лимита, отчета по задачам, регулярного демо и права остановки — это открытый кран. Вы платите за активность команды, но не всегда за приближение к бизнес-результату.
4. Fixed Price с дырявым объемом: фиксирована только первая иллюзия
Фиксированная цена полезна, когда объем работ действительно зафиксирован. FAR 16.202-1 формулирует это жестко: firm-fixed-price не корректируется из-за фактических затрат подрядчика, а подрядчик несет риск прибыли или убытка.
Но риск переносится на подрядчика только внутри согласованного объема. Если объем расплывчатый, фиксированная цена быстро превращается в серию доплат: новый экран, новый сценарий, новое поле, новая интеграция, новая роль, новая проверка.
5. Запросы на изменение без фильтра: «маленькие правки» становятся вторым проектом
Запросы на изменение — нормальная часть разработки. Проблема начинается, когда нет фильтра: что является исправлением ошибки, что входит в согласованный объем, а что является новой задачей.
В контрактной логике запрос на изменение обычно корректирует цену или срок, если изменение увеличивает стоимость или длительность работ. Это законно. Но без журнала изменений клиент быстро платит за то, что считал «очевидным исправлением».
6. Приемка без тестов: акт подписан, проблема осталась вам
Самый опасный акт — тот, который закрывает этап без демонстрации и критериев готовности. Формально работа принята. Практически бизнес получает экран, который открывается в идеальном сценарии, но ломается на реальных данных, слабой сети, старом устройстве или нестандартной роли пользователя.
Минимальная защита: критерии приемки по каждому сценарию, тестовые данные, список устройств/браузеров, проверка ошибок, доступ к аналитике, фиксация дефектов и правило, что баги в принятом объеме исправляются без отдельной оплаты. По теме проверок полезен отдельный разбор 13FOX про виды тестирования сайтов.
7. Права на код и доступы: вы оплатили работу, но не можете ей владеть
В России вопрос прав на программу для ЭВМ нельзя оставлять «по умолчанию». В зависимости от конструкции договора применимы разные нормы ГК РФ, включая статьи 1296 и 1297 о программах, созданных по договору или по заказу, а также правила лицензионного договора. Практический вывод простой: если права, исходники, макеты, документация и доступы не описаны явно, вы рискуете оплатить продукт, который трудно передать другой команде.
Проверьте, где лежит репозиторий, кто администратор App Store Connect, Google Play Console, Firebase, облака, домена, аналитики, CRM и платежей. Если все доступы у подрядчика, это уже не просто удобство. Это зависимость.
8. Облако, API и подписки: счет растет после релиза
Разработка заканчивается, а инфраструктурные расходы только начинаются. Серверы, хранилище, карты, SMS, пуши, почта, аналитика, AI API, мониторинг, Jira, Figma, CRM, платежи — все это может быть разумным набором. Но без ответственного за бюджет оно превращается в постоянную утечку.
Особенно опасны расходы по фактическому потреблению. Их легко недооценить на MVP и болезненно увидеть при росте. Поэтому в плане проекта должны быть лимиты, уведомления, прогноз месячного счета, кто оплачивает сервисы и что происходит, если лимит превышен.
9. Поддержка без SLA: вы платите за «быть на связи», а не за результат
Поддержка нужна почти любому живому продукту. Apple с 24 апреля 2025 года требует для загрузки приложений в App Store Connect сборку Xcode 16+ и актуальные SDK, а Google Play с 31 августа 2025 года требует для новых приложений и обновлений target Android 15/API 35+. Это означает, что мобильное приложение нельзя считать разовым активом без будущего бюджета.
Но поддержка должна быть описана: часы реакции, часы исправления, что считается инцидентом, что входит в абонентскую плату, что оплачивается отдельно, кто следит за SDK, безопасностью, резервными копиями и мониторингом. Иначе клиент платит за тревожную доступность, а не за устойчивость продукта.
4. Какие пункты договора нельзя пропускать
Хороший договор не делает подрядчика честным. Он делает проект проверяемым. Если пункты ниже отсутствуют, спор почти всегда уходит в область «мы так поняли», а это самая дорогая область разработки.
Состав работ
Экраны, роли, интеграции, админка, аналитика, документация и исключения из объема.
Критерии приемки
Что именно должно работать, на каких данных, устройствах, ролях и ошибочных сценариях.
Права и доступы
Исходный код, макеты, репозиторий, домен, облако, магазины приложений, ключи и документация.
Лимит изменений
Что считается багом, что считается правкой, сколько раундов включено и как считается новая задача.
Отчетность
Демо, журнал изменений, часы по задачам, прогноз рисков и понятное основание для следующего платежа.
Поддержка
SLA, обновления SDK, безопасность, резервные копии, мониторинг и граница абонентской платы.
5. Самое горячее: расходы, которые всплывают уже после разработки
У клиента часто есть иллюзия: «главное оплатить разработку, дальше продукт будет работать». На практике после релиза появляются платформенные и эксплуатационные расходы, которые нужно закладывать заранее.
App Store и Google Play — самый понятный пример. Apple Small Business Program дает комиссию 15% для разработчиков с proceeds до $1 млн за предыдущий календарный год. Google Play берет 15% на первые $1 млн годовой выручки enrolled developers и 30% сверх этого порога; для автопродлеваемых подписок ставка обычно 15%. Это не «скрытый обман», но это деньги, которые нельзя забывать в модели.
Vendor lock-in тоже перестал быть абстрактным термином. EU Data Act применяется с 12 сентября 2025 года и должен полностью убрать плату за смену поставщика, включая плату за исходящий перенос данных, с 12 января 2027 года. Но даже когда плата за перенос данных снижается, стоимость переписывания архитектуры, миграции и проверки совместимости остается.
Если подрядчик предлагает «быстро собрать на удобной платформе», спросите не только цену старта. Спросите цену выхода: как забрать данные, код, пользователей, платежи, аналитику и кто сможет поддерживать продукт без первого подрядчика.
6. Как контролировать разработку без технического директора
Вам не нужно становиться разработчиком. Но вам нужно перестать принимать проект на веру. Для этого достаточно простого управленческого контура.
До оплаты
Попросите декомпозицию работ, допущения оценки, список исключений, график демонстраций и правила изменения объема.
Во время этапа
Смотрите демо каждую неделю, принимайте не «процент готовности», а работающий сценарий, и сверяйте часы с задачами, а не с общим ощущением занятости.
Перед актом
Проверяйте критерии приемки, баг-лист, доступ к коду, документацию, список нерешенных рисков и прогноз следующего этапа.
Если вы только выбираете команду, полезно дополнительно прочитать материал про разработку приложения студией. Если вопрос в том, как не построить лишнее, посмотрите статью что такое MVP и когда его стоит заказать. А для общей логики этапов пригодится разбор этапов разработки сайта без слива бюджета.
7. Красные флаги перед следующим платежом
Если проект уже идет, не нужно устраивать войну с подрядчиком. Начните с спокойной проверки. Ниже признаки, после которых стоит поставить оплату на паузу до прояснения результата.
- Вам показывают статусы и проценты, но не показывают работающий сценарий.
- Нет доступа к репозиторию или он пустой до финальной оплаты.
- Правки смешаны с багами, и каждое обсуждение превращается в новую оценку.
- Смета следующего этапа не объясняет, что уже закрыто на предыдущем.
- Подрядчик не может назвать месячные расходы на облако, API, SMS, карты и мониторинг.
- В договоре нет понятной передачи прав, документации и доступов.
- Сроки сдвигаются, но список причин и решений не фиксируется письменно.
- Акт закрывает этап, хотя у вас нет тестовых сценариев и списка дефектов.
8. Источники и методика
Мы разделили данные на три группы. Первая — твердые источники: McKinsey/Oxford по перерасходам IT-проектов, CISQ по цене плохого качества ПО, Flexera 2026 по облачным расходам, официальные правила Apple, Google Play, Apple и Android по SDK/target API, нормы ГК РФ о программах для ЭВМ и договорных правах.
Вторая группа — аккуратные ориентиры: IBM Cost of a Data Breach 2025, Verizon DBIR 2025, FinOps Foundation State of FinOps 2026 и документы по EU Data Act. Они полезны для понимания риска, но не означают, что каждый проект несет именно такие потери.
Третья группа — исключенные или смягченные факты. Мы не использовали популярную цифру Standish CHAOS про 189% перерасход как ключевой аргумент: она исторически известна, но методологически спорна. Не переносили enterprise-кейсы вроде NHS, Lidl SAP или Queensland Health напрямую на малый бизнес: они полезны как иллюстрации масштаба, но не как прогноз для вашей сметы.
9. FAQ
Это правда юридическая статья?
Нет. Это управленческий разбор с юридическими зонами риска, а не правовое заключение. Перед подписанием договора лучше показать его профильному юристу, а статью использовать как чек-лист вопросов к подрядчику.
Если подрядчик работает по почасовой модели, это уже плохо?
Нет. Почасовая модель нормальна, когда объем нельзя надежно оценить заранее. Риск начинается там, где нет недельного лимита, прозрачного отчета, демонстрации результата и права остановить работы до следующего платежа.
Fixed Price защищает от перерасхода?
Только внутри четко описанного объема работ. Если ТЗ размыто, любой новый сценарий, интеграция, экран или правка легко становится отдельной доплатой.
Кому должны принадлежать права на код?
В договоре должно быть прямо написано, какие исключительные права, исходный код, дизайн-макеты, документация и доступы передаются заказчику, когда именно и в каком объеме.
Что проверить перед следующей оплатой?
Попросите демо, список закрытых задач, доступ к репозиторию, критерии приемки, журнал изменений, список рисков и прогноз допрасходов на следующий этап. Если этого нет, вы платите за туман.
13FOX может проверить уже начатый проект?
Да. Практичный формат для такого интента - разбор сметы, договора, доступа к коду и текущего результата перед следующим платежом. Цель не спорить с подрядчиком, а понять, где вы рискуете переплатить.
Перед следующим платежом проверьте, за что вы реально платите
В 13FOX можно принести смету, договор, список задач или уже начатый проект. Мы разберем, где есть риск переплаты, что должно быть результатом этапа, какие доступы нужно забрать и какие допрасходы всплывут после релиза.
Это не спор ради спора и не попытка сразу перетянуть проект. Цель проще: показать, где вы платите за результат, а где уже начали платить за неопределенность.