Коротко: чтобы понять, как выбрать подрядчика на разработку сайта, достаточно проверить четыре вещи — живые кейсы с работающими ссылками, детализированную смету по этапам, пункты договора о передаче исходников и правах, а также условия поддержки после запуска. Если хотя бы одно из этого исполнитель не показывает или отвечает уклончиво, риск получить недоделанный проект резко растёт.
Всё остальное — красивая презентация, количество сотрудников, наличие офиса — влияет на результат гораздо меньше, чем кажется. Ниже разберём каждый пункт по порядку: что именно спрашивать, какие ответы считать нормальными и на каких формулировках в договоре стоит остановиться.
Кейсы: смотрите не на картинки, а на ссылки и задачи
Первое, что делает заказчик, — открывает портфолио. Проблема в том, что портфолио легко нарисовать: макет в графическом редакторе выглядит убедительно и стоит копейки. Поэтому проверяйте не визуал, а три вещи: есть ли ссылка на работающий проект или страницу в сторе, описана ли исходная задача клиента и указан ли результат в измеримых величинах — сроки, объём функций, что изменилось после запуска.
Полезно открыть подборку кейсов и посмотреть, насколько подробно расписан ход работы. Например, в кейсе Check Apple видно, из чего складывается iOS-проект: логика проверки, интерфейс, публикация в сторе. А кейс «Наш двор» показывает другой тип задачи — сервис для сообщества, где важнее не витрина, а сценарии взаимодействия людей. Разные типы задач в портфолио — хороший знак: команда не собирает один и тот же шаблон.
Отдельно спросите, какую часть работы делала команда. Бывает, что подрядчик показывает проект, где он рисовал только баннеры. Прямой вопрос «что именно вы здесь делали и можно ли связаться с заказчиком» решает многое: адекватный исполнитель отвечает спокойно и конкретно.
Смета: почему «сайт под ключ за одну сумму» — плохой знак
Хорошая смета разбита на блоки: аналитика и структура, дизайн, вёрстка, программирование, интеграции, тестирование, запуск. Каждый блок с часами или фиксированной суммой. Тогда вы понимаете, за что платите, и можете отказаться от лишнего — например, отложить сложную анимацию на второй этап.
Второй маркер — исполнитель объясняет, от чего зависит вилка. Простой лендинг и корпоративный сайт с каталогом отличаются в разы, поэтому диапазоны на странице цен начинаются от 15 000 ₽ за небольшие задачи и доходят до от 450 000 ₽ за крупные проекты. Мобильная разработка считается отдельно: iOS-приложение стартует от 250 000 ₽, потому что там всегда есть серверная часть, тестирование на устройствах и публикация.
Насторожить должны две крайности. Первая — цена названа за минуту разговора без единого уточняющего вопроса. Вторая — смета состоит из одной строки «разработка сайта». В обоих случаях в середине проекта почти наверняка появятся «это не входило в объём» и доплаты.
Этапы и оплата: как не остаться без денег и без проекта
Нормальная схема — деление на этапы с приёмкой каждого. Классика: предоплата в начале, платёж после утверждения дизайна, платёж после сдачи функционала, остаток при запуске. Размер первого транша обычно 30–50%: работать полностью без предоплаты никто не станет, но и 100% вперёд за трёхмесячный проект — плохая идея.
В договоре должно быть написано, что считается сдачей этапа и сколько дней у вас есть на замечания. Формулировка «работы считаются принятыми, если заказчик не направил мотивированный отказ в течение 5 рабочих дней» — рабочая и защищает обе стороны. Также проверьте, сколько бесплатных правок входит в этап: разумный вариант — два-три круга правок по дизайну, дальше по часам.
Спросите про порядок изменения объёма. В любом проекте появляются новые идеи, и вопрос не в том, будут ли они, а в том, как оформляются: дополнительным соглашением с новой сметой и сроком или устной договорённостью, о которой через месяц никто не вспомнит.
Исходники, доступы и права — самый недооценённый пункт
Здесь теряют больше всего. После оплаты вам должны передать исходный код, макеты дизайна, доступы к хостингу, домену, репозиторию, панели администратора и аккаунтам сторонних сервисов. Домен регистрируйте на себя или на свою компанию с самого начала — это пять минут и снимает целый класс проблем.
В договоре ищите пункт об отчуждении исключительных прав на результат работ после полной оплаты. Если написано только про «право использования», формально код остаётся у подрядчика. Для приложения добавьте отдельный вопрос: на чей аккаунт разработчика идёт публикация в App Store. Приложение на аккаунте подрядчика — это ситуация, когда сменить команду можно только с переносом или переизданием.
Ещё один практичный маркер: попросите показать, как организован проект технически. Если код лежит в нормальном репозитории с историей коммитов, а не архивом на рабочем столе, передача пройдёт без сюрпризов.
Поддержка после запуска: что входит и по какой цене
Запуск — не финал. Сайт нужно обновлять, приложение — адаптировать под новые версии iOS, интеграции ломаются, когда меняется API стороннего сервиса. Уточните заранее: есть ли гарантийный период на ошибки (обычно 1–3 месяца, и правка багов в нём бесплатна), чем баг отличается от доработки в понимании подрядчика, есть ли абонентская поддержка и сколько часов в неё входит.
У мобильных проектов это критично: регламентную поддержку iOS стоит закладывать в бюджет сразу, потому что раз в год выходит новая версия системы и приложение приходится проверять и обновлять. Для сайтов история спокойнее, но и там нужны обновления CMS, резервные копии и контроль форм — заявки любят перестать приходить незаметно.
Обратите внимание на скорость реакции. Не «ответим в течение недели», а понятное время: например, реакция в рабочий день, критичные сбои — в течение нескольких часов. И спросите, кто будет вести проект после сдачи: тот же разработчик или новый человек, который увидит код впервые.
Пять вопросов, которые стоит задать на первом созвоне
Спросите: какие задачи вы решали, похожие на мою, и можно ли посмотреть работающий результат. Из чего складывается сумма и что изменит её в большую сторону. Как делится проект на этапы и что я получаю в конце каждого. Кому принадлежит код, домен и аккаунт разработчика после оплаты. Что происходит с проектом через полгода после запуска и сколько это стоит.
Ответы на эти пять вопросов дают больше, чем часовая презентация. Если исполнитель на каждом уточнении переводит разговор на «мы сделаем красиво», это уже ответ. Если предлагает начать с небольшого этапа — например, с прототипа или лендинга вместо большого портала сразу — это, наоборот, признак трезвого подхода: вы проверяете команду на маленьком бюджете, а не на всём проекте.
Вывод
Выбор подрядчика на разработку сайта или приложения — это проверка прозрачности, а не поиск самой низкой цены. Живые кейсы с задачами и ссылками, смета по блокам, оплата по этапам с приёмкой, чёткий пункт о передаче исходников и прав, понятные условия поддержки — пять фильтров, которые отсеивают большинство проблемных исполнителей ещё до подписания договора. Потратьте на эту проверку один вечер: она дешевле, чем переделывать проект с другой командой.