Заказная разработка в 2026 году: как заказчику без технических знаний не переплатить и не получить плохой код
Рынок ИТ замедляется, бюджеты сокращаются, а нейросети меняют сам процесс разработки. Что из этого следует для заказчика, который не разбирается в программировании, но хочет получить рабочий продукт и не переплатить? Разбираем по шагам: от выбора подрядчика до приёмки готовой работы.
Раньше выбор подрядчика сводился к трём вопросам: сколько стоит, как быстро и есть ли отзывы. В 2026 году к ним добавился четвёртый: как исполнитель использует искусственный интеллект и кто отвечает за качество результата.
Эта статья написана для тех, кто заказывает сайт, веб-сервис, личный кабинет, интеграцию или другой цифровой продукт и не хочет вникать в технические подробности. Мы не будем перегружать вас терминами. Вместо этого дадим понятные вопросы, критерии и признаки, по которым можно отличить надёжного исполнителя от рискованного.
Что происходит на рынке
По материалу ГК «КОРУС Консалтинг» от 1 апреля 2026 года, рост российского ИТ-рынка по итогам 2025 года замедлился до 10% против 21,9% годом ранее. Компании оптимизируют расходы и смещают приоритеты в сторону проектов с короткими сроками и быстрой отдачей.
При этом спрос на кастомную разработку не исчезает. Причина простая: типовые решения не всегда справляются с уникальными и критичными для бизнеса процессами. Крупным компаниям с нагруженными ИТ-системами стандартных коробочных продуктов часто не хватает.
Среди барьеров эксперты называют высокую ключевую ставку и рост налоговой нагрузки, которые удорожают капитал и сдерживают инвестиции в ИТ. Дополнительное давление создаёт рынок труда: компании ищут специалистов, которые умеют осознанно использовать ИИ-инструменты, а таких разработчиков с реальным опытом не хватает.
Для заказчика из этого следует практический вывод: деньги получают проекты, которые решают конкретную задачу и окупаются быстро. Проекты «на вырост» без ясной цели оказываются под ударом первыми. А значит, к формулировке задачи и бюджету стоит подходить внимательнее, чем раньше.
Куда уходят бюджеты на заказную разработку
Эксперты КОРУС выделяют четыре сценария, на которые компании по-прежнему готовы тратить деньги. Они касаются в основном крупного бизнеса, но логика полезна и для небольших компаний.
1. Проекты ИИ-трансформации. Компании пробуют применять ИИ в производстве, продажах, маркетинге и ИТ. Пилотных проектов много, но эффект получают не все: большинство инициатив останавливается на этапе проверки гипотез. Результат становится заметным, когда успешные сценарии масштабируют.
2. Модернизация устаревших систем. ИТ-ландшафты устаревают быстрее, чем их успевают переделывать. Опыт 2025 года показал, что поэтапное обновление эффективнее попыток переписать всё сразу.
3. ИТ-задачи при слиянии компаний и локализации бизнеса. Нужно объединить разрозненные системы в одну управляемую платформу.
4. Совместные отраслевые проекты. Компании одной отрасли объединяются, чтобы вместе разработать типовой функционал и доработать специфику под себя.
Общий признак всех четырёх сценариев: бюджеты получают инициативы, которые устраняют системные ограничения бизнеса и сохраняют управляемость и скорость изменений. Для малого бизнеса это означает простое правило: заказывайте разработку под конкретную боль, а не «потому что так принято».
Как нейросети меняют разработку
Искусственный интеллект действительно ускоряет работу. Опытные специалисты используют его как инструмент, чтобы быстрее справляться с рутиной: писать типовой код, находить ошибки, готовить тесты. Эксперты КОРУС также приводят прогноз Gartner: к 2030 году в 80% компаний небольшие команды с ИИ-поддержкой заменят крупные подразделения разработки.
Среди технологических тенденций 2026 года они называют разработку, где генеративный ИИ используется по умолчанию, работу с наборами ИИ-агентов, которые пишут и тестируют код, внутренние платформы для разработчиков, модульную архитектуру из небольших сервисов и собственный контур безопасности для работы с ИИ.
Но у этой медали есть обратная сторона. Те же эксперты отмечают, что часть менее опытных разработчиков воспринимает ИИ как автономного исполнителя и поручает ему смысловую часть работы, не проверяя результат. В краткосрочной перспективе качество падает, а ошибки множатся быстрее. В долгой перспективе возникает дефицит специалистов, которые действительно понимают архитектуру систем.
В заказной разработке цена таких ошибок выше: решение глубоко встраивается в бизнес-процессы, и исправлять архитектурные просчёты дорого. Представьте, что фундамент дома заложили с ошибкой. Пока дом не построен, поправить его легко. Когда стены уже стоят, исправление обходится в разы дороже.
Иными словами, вопрос не в том, использует ли подрядчик нейросети. Использует, и это нормально. Вопрос в том, кто проверяет результат.
Что это значит для заказчика: плюсы и риски
Плюсы. Часть работ действительно становится быстрее и дешевле: типовые экраны, формы, простые интеграции, тесты. Прототип можно получить раньше, а значит, раньше проверить идею на реальных пользователях. Небольшая команда с опытными специалистами и ИИ-инструментами способна сделать то, для чего раньше требовался целый отдел.
Риски. Подрядчик может использовать нейросети как способ сэкономить на квалификации: нанять дешёвых исполнителей и положиться на сгенерированный код. Снаружи результат выглядит нормально: страницы открываются, кнопки нажимаются. Проблемы обнаруживаются позже: при росте нагрузки, добавлении функций, атаке на безопасность или смене разработчика.
Ваша задача как заказчика — не запрещать ИИ, а требовать прозрачности и контроля качества. Это возможно, даже если вы не разбираетесь в коде.
Шесть вопросов, которые стоит задать подрядчику
1. Кто проверяет код и архитектуру? Хороший ответ: опытный специалист проводит ревью, а не только нейросеть пишет и сама же оценивает свой результат. Эксперты КОРУС рекомендуют именно такую практику: регулярное ревью архитектуры силами старших специалистов.
2. Из каких этапов состоит проект и что я получаю на каждом? Каждый этап должен заканчиваться чем-то, что можно посмотреть и принять: макетом, прототипом, рабочей версией. Если на вопрос отвечают «увидите, когда будет готово», это тревожный сигнал.
3. Как фиксируется стоимость? Смета с разбивкой по этапам согласуется до начала работ. Расплывчатое «посмотрим по ходу» часто заканчивается доплатами.
4. Кому принадлежат исходный код и права на результат? Вы должны получить исходники, доступы и права. Иначе вы окажетесь привязаны к одному исполнителю и не сможете без него ничего изменить.
5. Кто и как поддерживает продукт после запуска? Уточните время реакции на сбои, порядок доработок и стоимость сопровождения. Продукт после запуска продолжает требовать внимания: обновлений, исправлений, поддержки новых версий систем.
6. Подписываете ли вы соглашение о неразглашении? Если вы делитесь процессами и данными, это базовая защита. Серьёзный исполнитель подпишет его без возражений.
Как читать смету и не пропустить скрытые расходы
Смета — главный документ, который защищает вас от неожиданных доплат. Но читать её нужно внимательно. Вот на что обратить внимание.
Разбивка по этапам. Смета в одну строку «разработка сайта — столько-то» не даёт возможности контролировать работу. Хорошая смета показывает, сколько стоит аналитика, дизайн, разработка, тестирование, запуск и каждый этап отдельно.
Что входит в результат. Уточните, что именно вы получите: макеты, исходный код, документацию, инструкции, обучение сотрудников. Если что-то не указано, считайте, что его нет.
Что не входит. Обычно отдельно оплачиваются хостинг, домен, лицензии сторонних сервисов, платные библиотеки, наполнение контентом. Спросите прямо: какие расходы мне предстоят помимо этой сметы?
Правила изменений. В ходе работы требования неизбежно уточняются. Узнайте заранее, как оформляются изменения: что входит в стоимость, а что считается дополнительной работой и как оценивается.
Сроки и ответственность. Сроки должны быть указаны по этапам. Уточните, что происходит при срыве сроков по вине исполнителя и по вашей стороне, например при задержке согласований.
Гарантийный период. После сдачи проекта в нём часто находятся ошибки. Выясните, на какой срок распространяется бесплатное исправление дефектов и как оно оформляется.
Как составить задание, которое понимает подрядчик
Многие проблемы в проектах возникают не из-за плохой разработки, а из-за расплывчатых требований. Заказчик имеет в виду одно, исполнитель понимает другое, и обе стороны разочарованы. Чтобы этого избежать, подготовьтесь к разговору.
Опишите проблему, а не решение. Вместо «нужен личный кабинет» расскажите, что сейчас происходит: клиенты звонят и спрашивают статус заказа, менеджеры тратят на это три часа в день. Исполнитель сможет предложить варианты, в том числе более простые и дешёвые.
Назовите, кто будет пользоваться. Клиенты, сотрудники, партнёры. У каждой группы свои потребности и уровень подготовки.
Определите, как вы поймёте, что всё получилось. Например: «менеджеры тратят на ответы о статусе не больше 30 минут в день» или «заявки с сайта автоматически попадают в CRM». Измеримый результат помогает и при приёмке работ.
Покажите примеры. Ссылки на сайты и сервисы, которые нравятся вам, и те, которые не нравятся, объяснят вкусы лучше длинного описания.
Назовите ограничения. Бюджет, сроки, системы, с которыми нужна интеграция, требования по безопасности и хранению данных.
Как не переплатить: пять простых правил
- Начинайте с минимального рабочего продукта. Сначала запустите ключевую функцию, посмотрите на реакцию пользователей, затем развивайте. Это дешевле, чем строить «идеальную систему» сразу.
- Не заказывайте кастом там, где хватит готового решения. Заказная разработка оправдана, когда типовые сервисы не закрывают ваш процесс.
- Дробите проект на этапы. Крупные проекты, которые делают целиком и сразу, чаще выходят за сроки и бюджет, чем поэтапные. Эксперты КОРУС рекомендуют приоритизацию и поэтапность.
- Закладывайте сопровождение сразу. Продукт после запуска продолжает требовать обновлений, и лучше понимать эти расходы заранее.
- Не экономьте на аналитике. Время, потраченное на уточнение требований в начале, окупается многократно: ошибки, обнаруженные на старте, исправляются дёшево, а в конце проекта дорого.
Красные флаги: когда стоит насторожиться
Некоторые признаки позволяют заподозрить проблемы ещё до подписания договора. Мы не говорим, что наличие одного из них означает недобросовестность, но повод для дополнительных вопросов он даёт.
- Цена названа сразу, без вопросов о ваших задачах. Невозможно оценить проект, не поняв, что именно нужно сделать.
- Стоимость заметно ниже остальных предложений без объяснения, за счёт чего.
- Исполнитель обещает сделать «всё и сразу» за короткий срок.
- Нет описания этапов и промежуточных результатов.
- Уклончивые ответы на вопросы о правах на исходный код.
- Нет информации о том, кто именно будет работать над проектом.
- Отказ подписать соглашение о неразглашении.
- Давление: «скидка действует только сегодня».
Как принимать работу по этапам
Приёмка — момент, когда заказчик может влиять на качество. Но многие не знают, как к ней подготовиться, и принимают работу «на глаз». Вот простой подход.
Сравните с задачей. Возьмите описание того, что должно получиться, и пройдите по пунктам. Работает ли каждая функция, как договаривались?
Проверьте на реальных сценариях. Пусть сотрудники, которые будут пользоваться продуктом, выполнят свои обычные действия. Часто именно они находят неудобства, которых не видно со стороны.
Проверьте «неудобные» случаи. Что будет, если ввести пустое значение, очень длинный текст, неправильный телефон? Как система ведёт себя на телефоне и в разных браузерах?
Зафиксируйте замечания письменно. Список правок с описанием, что не так и как должно быть, помогает избежать недопонимания.
Не принимайте этап, пока замечания не исправлены. Оплата и приёмка этапа должны быть связаны: деньги за выполненную и проверенную работу.
Убедитесь, что вы получили всё необходимое. Доступы, исходный код, документацию, инструкции. Если вы получите их только в конце проекта, вы рискуете их не получить.
Ориентиры по срокам
Заказчики часто спрашивают, сколько времени обычно занимает разработка. Точный ответ зависит от задачи, но общее представление дают ориентиры, которые мы публикуем на своём сайте:
- интеграции и API: от 2 до 5 недель;
- UI/UX-дизайн и прототипы: от 3 до 6 недель;
- веб-сервисы и корпоративные порталы: от 6 до 16 недель;
- мобильные приложения: от 8 до 18 недель.
Это ориентиры, а не обещания: итоговые сроки фиксируются после оценки конкретной задачи. Если же вам называют срок вдвое короче без объяснения причин, стоит выяснить, за счёт чего он достигается.
Как устроена работа в ИТБРАТ
Мы работаем по регламенту из шести этапов: аудит и аналитика, стратегия и концепция, дизайн и прототипирование, разработка и интеграция, тестирование и запуск, поддержка и развитие. Каждый этап заканчивается демонстрацией и приёмкой, а смета с разбивкой по этапам согласуется до начала работ.
По завершении мы передаём исходный код, инфраструктуру и права на результат, а соглашение о неразглашении подписываем до первого созвона. Для поддержки действует SLA на реакцию от 15 минут в рабочее время. Над проектом работает выделенная команда: аналитик, архитектор, дизайнер, разработчики, тестировщик и DevOps-инженер, с одним ответственным за результат.
Подробнее о том, что мы разрабатываем: веб-приложения и сервисы.
Вывод
В 2026 году заказчику важнее всего не гнаться за дешевизной и не бояться ИИ, а требовать прозрачности: из каких этапов состоит работа, кто проверяет результат и что вы получите на выходе. Подрядчик, который готов спокойно ответить на эти вопросы, как правило, и работает спокойнее.
Помните три принципа. Первый: формулируйте проблему, а не решение. Второй: дробите проект на этапы и принимайте каждый. Третий: сразу договаривайтесь о правах, поддержке и ответственности. Эти правила работают независимо от того, пишут код люди, нейросети или те и другие вместе.
Источники: материал ГК «КОРУС Консалтинг» «Кастом в эпоху ИИ: каким будет 2026 год для ИТ-директоров» (1 апреля 2026); описание регламента и ориентировочных сроков на сайте itbrat.pro.
Материал подготовлен ООО «ИТБРАТ». Мы занимаемся разработкой программного обеспечения, интеграциями и автоматизацией бизнес-процессов. Расскажите о задаче на сайте или в Telegram @itbrat, и инженер вернётся с вариантами решения, сроками и вилкой бюджета в течение 4 рабочих часов.
Часто задаваемые вопросы
Когда стоит заказывать разработку, а когда хватит готового сервиса?
Если типовой сервис закрывает ваш процесс, берите его. Заказная разработка оправдана, когда процесс уникален, критичен для бизнеса и готовые решения не справляются.
Можно ли доверять разработке с помощью нейросетей?
Да, если результат проверяют опытные специалисты. ИИ ускоряет рутинные операции, но ответственность за архитектуру и качество остаётся за людьми.
Как избежать доплат в процессе разработки?
Согласуйте смету с разбивкой по этапам до старта, зафиксируйте состав работ в техническом задании, договоритесь о порядке внесения изменений и принимайте результат на каждом этапе.
Что должен передать подрядчик после завершения проекта?
Исходный код, доступы к инфраструктуре, документацию и права на результат. Это стоит прописать в договоре.
Как понять, что подрядчик надёжен?
Он прозрачно описывает этапы, называет, кто проверяет качество, фиксирует смету и готов подписать соглашение о неразглашении.
Сколько времени занимает разработка?
Зависит от типа продукта и сложности. Ориентиры: интеграции занимают недели, веб-сервисы и порталы от полутора до четырёх месяцев, мобильные приложения дольше. Точный срок называют после оценки задачи.
Нужно ли составлять техническое задание самому?
Не обязательно в полном объёме. Достаточно описать проблему, пользователей, ограничения и измеримый результат. Подробное техническое задание подрядчик подготовит на этапе аналитики и согласует с вами.
Что делать, если проект вышел за сроки или бюджет?
Выясните причину: изменились требования, возникли технические сложности или проблема в организации работы. Зафиксируйте решение письменно, пересмотрите план по этапам и не принимайте дополнительных обязательств без согласованной сметы.
