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

Сравнивайте не обещания, а будущий результат и способ его проверить

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

До запроса сметы опишите задачу обычными словами: кто придёт на сайт, что этому человеку нужно сделать и какое событие бизнес считает результатом. Это может быть заявка с заполненными контактами, расчёт стоимости, звонок, запись или оплаченный заказ. Когда результат определён, предложения разных исполнителей можно сравнивать по одинаковым критериям.

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

Проверьте портфолио как рабочий продукт, а не как галерею картинок

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

Попросите подрядчика объяснить свою роль в каждом примере. Команда могла делать весь продукт, только вёрстку или отдельный экран. Честный ответ важнее громкого логотипа в списке клиентов. Если результат проекта нельзя подтвердить, не используйте неподтверждённые цифры как основание для решения.

Разберите смету по результатам, этапам и границам

Смета одной строкой не позволяет понять, что произойдёт, если изменится объём контента или появится новая интеграция. Попросите разложить проект на понятные результаты: исследование и структура, прототип, дизайн, разработка, наполнение, тестирование, аналитика, запуск и гарантийные исправления.

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

• Фиксированная цена подходит для согласованного и стабильного объёма.
• Поэтапная оценка удобна, когда первую версию нужно запустить быстро.
• Почасовая модель оправдана для развития продукта с меняющимися задачами.
• Резерв на неизвестные интеграции лучше обозначить заранее, а не прятать в общей сумме.
• Любое изменение состава работ должно сопровождаться оценкой влияния на срок и цену.

Задайте подрядчику 12 вопросов до подписания договора

Ответы не обязаны быть длинными. Важно, чтобы они были конкретными, проверяемыми и совпадали с текстом договора и сметы.

• Как вы проверите, что сайт решает задачу пользователя, а не только соответствует макету?
• Какой состав первой версии вы рекомендуете и что сознательно откладываете?
• Кто отвечает за структуру, тексты, дизайн, разработку и тестирование?
• Когда мы увидим первый рабочий результат и как часто будут демонстрации?
• Какие изменения входят в цену и как оцениваются новые требования?
• Как будут проверяться мобильная версия, формы, ошибки и доступность интерфейса?
• Какие меры защиты применяются к формам, данным и административной части?
• Кому принадлежат домен, исходный код, дизайн и учётные записи после оплаты?
• Как сохраняются существующие URL, метаданные и поисковый трафик при редизайне?
• Какие события будут передаваться в Метрику или другую систему аналитики?
• Что входит в запуск, гарантию и поддержку после публикации?
• Как заказчик получит доступы, резервную копию и инструкцию по управлению сайтом?

Зафиксируйте измеримые критерии приёмки

Фраза «современный и удобный сайт» не является критерием приёмки: каждый понимает её по-своему. Замените оценочные формулировки проверяемыми сценариями. Например, форма принимает обязательные поля, показывает состояние отправки, передаёт заявку менеджеру и создаёт целевое событие только после успешного ответа сервера.

Для доступности и безопасности одного автоматического отчёта недостаточно. W3C указывает, что проверка доступности сочетает автоматизированные тесты и оценку человеком, а OWASP ASVS можно использовать как основу требований к проверке безопасности веб-приложений. Глубина проверки должна соответствовать риску проекта: публичный лендинг и личный кабинет с персональными данными требуют разного уровня контроля.

• Основные страницы возвращают код 200 и открываются по HTTPS.
• Сайт работает на согласованных размерах экранов и в актуальных браузерах.
• Формы проходят успешный и ошибочный сценарии.
• Клавиатурой можно добраться до главных интерактивных элементов.
• У изображений заданы размеры и содержательные альтернативные подписи, когда они нужны.
• События аналитики не содержат телефон, email и другие персональные данные.
• Критические замечания безопасности исправлены до публикации.

Не отдавайте подрядчику контроль над активами бизнеса

Домен, хостинг, аналитика, рекламные кабинеты и репозиторий должны быть оформлены на заказчика или переданы ему по понятной процедуре. Подрядчику выдаются рабочие доступы с необходимыми правами, но бизнес не должен зависеть от единственного личного аккаунта исполнителя.

В договоре полезно зафиксировать момент передачи исключительных прав, состав передаваемых материалов и условия использования сторонних компонентов. После запуска заказчик должен получить список сервисов, доступы, резервную копию, инструкцию и контакты для поддержки.

Сравните предложения в одной таблице и выберите управляемый риск

Сведите финалистов в таблицу, где строки — одинаковые критерии, а столбцы — подрядчики. Не пытайтесь превратить выбор в искусственную сумму баллов: отдельно отметьте критические условия, без которых проект нельзя начинать.

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

• Релевантный опыт и проверяемые живые проекты.
• Понятный состав первой версии.
• Сроки демонстраций и критерии приёмки.
• Цена, исключения и порядок изменения объёма.
• Права, доступы и передача результата.
• SEO, аналитика, безопасность и поддержка.
• Качество коммуникации и скорость ответа на конкретные вопросы.