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

Тип подрядчика под тип проекта

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

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

Отдельная строка — инхаус-команда. Её берут не потому, что она дешевле (она почти никогда не дешевле на дистанции до года), а потому что продукт требует постоянного развития и накопления знаний внутри компании. Экономика простая: команда из тимлида, двух разработчиков, дизайнера и тестировщика в 2026 году обходится в несколько сотен тысяч рублей ежемесячно вне зависимости от того, есть ли для неё работа. Инхаус оправдан там, где работы гарантированно хватает на годы вперёд.

Чтобы этот текст не был рекламой самого себя: Veltos.Tech по этой классификации — небольшое агентство, и все ограничения соответствующей строки к нам применимы в полной мере. Мы хорошо закрываем проекты в диапазоне от лендинга до веб-приложения и не подходим для задач уровня системного интегратора с многолетними интеграциями в корпоративный ландшафт. Если ваш проект из второй категории, честный ответ — искать другой класс подрядчика, и все вопросы ниже стоит задавать нам ровно так же, как всем остальным.

25 вопросов на первом созвоне

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

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

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

• Команда: кто конкретно будет делать проект — имена, роли, уровень?
• Команда: сколько ещё проектов у этих людей параллельно?
• Команда: люди в штате или привлекаются на подряд?
• Команда: кто будет моей точкой контакта и кто его подменяет в отпуске?
• Команда: что происходит, если ключевой разработчик уйдёт в середине проекта?
• Процесс: опишите, что происходит на третьей неделе проекта.
• Процесс: где я вижу задачи и прогресс, и получу ли я туда доступ?
• Процесс: как часто будут демонстрации промежуточных результатов?
• Процесс: как оформляется изменение объёма работ и кто его согласует?
• Процесс: кто тестирует и по какому чек-листу?
• Оценка: сколько часов заложено на каждый этап?
• Оценка: что входит в цену, а что оплачивается отдельно?
• Оценка: какие риски вы видите в моём проекте и во что они могут вылиться?
• Оценка: при каких условиях смета вырастет и на сколько?
• Оценка: сколько итераций правок включено в дизайн и в разработку?
• Коммуникация: в каком канале общаемся и какое время реакции?
• Коммуникация: кто пишет тексты и готовит фотографии?
• Коммуникация: что вам нужно от меня и в какие сроки, чтобы не сорвать график?
• Коммуникация: как вы сообщаете о срыве срока и за сколько дней?
• Гарантии: какой гарантийный срок и что в него входит?
• Гарантии: что считается дефектом, а что новой задачей?
• Гарантии: покажите два проекта в моей нише и расскажите, что там пошло не так.
• Передача: кому принадлежат исходники, дизайн-макеты и права на код?
• Передача: на кого регистрируются домен, хостинг и лицензии?
• Передача: что я получу на выходе, кроме работающего сайта, и как выглядит инструкция?

Как правильно читать портфолио

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

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

Самая сильная проверка — позвонить клиенту из кейса. Подрядчик, который уверен в своей работе, даст контакт без вопросов; отказ под предлогом NDA бывает обоснован, но два отказа подряд — это уже сигнал. Спрашивать бывшего клиента нужно не «всё ли понравилось», а конкретное: укладывались ли в срок, сколько раз менялась смета, как реагировали на баги после запуска, стали бы работать снова. Пятиминутный звонок закрывает больше рисков, чем час презентации.

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

Красные флаги

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

Второй флаг — непрозрачная смета. Одна строка «разработка сайта — 450 000 ₽» не поддаётся ни сравнению с другими предложениями, ни контролю по ходу проекта, ни частичной приёмке. Просьба разбить смету по этапам и часам — абсолютно нормальная, и отказ её выполнить содержательно означает одно: точной оценки не существует, названа приблизительная цифра. Сюда же относится смета, где отсутствуют тестирование, контент и запуск: эти работы никуда не денутся, их просто оплатят позже.

Третья группа флагов — про обещания и обязательства. «Сделаем за неделю» на проекте, где только согласование дизайна занимает две, означает либо шаблон, либо невыполнимое обещание. Работа без договора и без ТЗ означает, что спорить о результате будет не с чем. Отказ показать команду, невнятный ответ про передачу исходников, регистрация домена и хостинга на подрядчика, предоплата 100% до начала работ — каждый пункт по отдельности объясним, но два и больше вместе описывают вполне определённую бизнес-модель.

• Точная цена названа до вопросов о задаче, интеграциях и объёме контента.
• Смета одной строкой, без этапов, часов и перечня исключений.
• Обещание сроков, которые физически не помещаются в объём работ.
• Работа без договора, без ТЗ или «договор подпишем позже, давайте начнём».
• Отказ назвать конкретных исполнителей и их занятость.
• Невнятный ответ на вопрос о правах на код и передаче исходников.
• Домен, хостинг и лицензии оформляются на подрядчика, а не на вас.
• Предоплата 100% до начала работ на проекте дольше двух недель.
• В портфолио нет ни одного живого сайта, который можно открыть прямо сейчас.
• На вопрос «что пошло не так на прошлых проектах» отвечают, что всегда всё идёт по плану.

Как сравнивать несравнимые коммерческие предложения

Получить на один бриф предложения на 180 000, 450 000 и 1 100 000 ₽ — нормально, и это не значит, что кто-то из троих неправ. Это значит, что каждый прочитал бриф по-своему и оценил свою версию проекта. Сравнивать такие предложения по итоговой цифре бессмысленно: сначала их нужно привести к общему виду. Нормализация занимает пару часов и почти всегда меняет порядок предпочтений, потому что самое дешёвое предложение после приведения к общему объёму нередко оказывается средним по цене.

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

Второй слой нормализации — часы и сеньорность. Спросите у каждого подрядчика, сколько часов заложено и по какой ставке. Если предложение на 180 000 ₽ содержит 120 часов, а на 450 000 ₽ — 300 часов, вы сравниваете не цену, а объём внимания к проекту. Третий слой — что оплачивается сверху: правки после лимита итераций, доработки после приёмки, поддержка в первый месяц, продление лицензий. Именно эти строки создают разницу между сметой и итоговым платежом.

Что обязательно должно быть в договоре

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

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

Второй по важности блок — этапы и приёмка. Должно быть написано, из каких этапов состоит работа, что является результатом каждого, в какой срок заказчик обязан его принять или дать мотивированный отказ, и что происходит, если он молчит. Пункт про молчаливую приёмку через N рабочих дней защищает подрядчика, пункт про мотивированный отказ защищает вас. Оба нужны: односторонний договор всегда порождает конфликт, просто на разных этапах.

Дальше — обязательный минимум остальных пунктов: гарантийный период 3–6 месяцев с определением, что считается дефектом (несоответствие ТЗ), а что новой задачей; порядок и лимит правок; передача доступов, репозитория и учётных записей в течение конкретного срока после финального акта; порядок расторжения с расчётом за фактически выполненный объём; NDA, если вы передаёте данные клиентов или коммерческие условия. И проверьте, на кого оформлены домен, хостинг и лицензии: это самая частая точка, где заказчик оказывается заложником.

• Этапы, результат каждого этапа и срок приёмки с мотивированным отказом.
• Исключительные права на код и дизайн в полном объёме, включая право на модификацию.
• Доступы, репозиторий, домен и хостинг оформлены на заказчика.
• Гарантийный период 3–6 месяцев и определение дефекта.
• Порядок правок: сколько включено, что стоит дальше, как оформляется.
• Порядок расторжения и расчёт за фактически выполненный объём.
• NDA, если передаются данные клиентов, цены или внутренние процессы.

Тревожные признаки в середине проекта и как выйти вовремя

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

Проверка занимает один запрос: попросите доступ к репозиторию и к тестовому стенду. Живой проект имеет историю коммитов с равномерным ритмом и работающую сборку, которую можно открыть в браузере. Мёртвый проект даёт отговорки: «стенд поднимем к демо», «код закрыт по политике безопасности», «покажем на следующей неделе». Если два раза подряд вы не получили доступ к работающей версии, статус проекта вам неизвестен вне зависимости от того, что написано в отчётах.

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

Реалистичная оценка потерь: при выходе на середине проекта вы теряете обычно 30–50% вложенного, потому что часть работы придётся переделать, а новая команда потратит время на разбор чужого кода. При доведении заведомо провального проекта до конца потери составляют 100% плюс упущенное время. Арифметика в пользу раннего выхода почти всегда, и единственная причина, по которой люди тянут, — нежелание признать, что предыдущее решение было ошибочным.

Частые вопросы

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Аудит сайта: технический, SEO и UXПрежде чем менять дизайн, увеличивать бюджет на рекламу или писать техподдержке «сайт стал хуже работать», разберитесь, что на самом деле происходит. Аудит — это один отчёт, который сводит техническое состояние, SEO и юзабилити в список: что горит, что важно, а что можно не трогать.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.

Читать дальше

• Техническое задание на сайт: структура, шаблон и разбор ошибокТЗ — это не бюрократия, а рычаг: всё, что не соответствует заданию, подрядчик исправляет бесплатно. Разбираем структуру по разделам, показываем заполненный пример для корпоративного сайта и объясняем, как писать критерии приёмки, которые можно проверить.
• Сколько стоит разработка сайта в 2026: разбор сметы по строкамРазбираем смету на разработку сайта построчно: сколько стоит аналитика, дизайн, вёрстка, бэкенд и интеграции, какие расходы всегда появляются после запуска и на чём можно сэкономить без последствий.
• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.