Как выбрать подрядчика для разработки сайта: критерии и вопросы до договора
Выбирать подрядчика для разработки сайта удобнее по одинаковому заданию и проверяемым результатам каждого этапа. Попросите несколько команд оценить одну структуру страниц, функции и интеграции, затем сравните не только итоговую сумму, но и то, что входит в нее: аналитику, дизайн, контент, перенос данных, тестирование и поддержку после запуска.
Этот порядок подходит компании, которая заказывает корпоративный сайт, каталог или интернет-магазин. Для небольшого лендинга часть проверок можно сократить. Для сайта с личным кабинетом, обменом с 1С или CRM, несколькими языками и поисковым трафиком они особенно важны.
Короткий ответ: хороший выбор начинается с брифа, одинакового для всех участников. До договора получите состав работ, критерии приемки, список доступов и прав, план запуска и границы поддержки. По этим документам можно сравнивать предложения без догадок.
Что подготовить до запроса цены
Подрядчики не смогут дать сопоставимые оценки, если один получил описание «нужен современный сайт», а второй — перечень страниц и интеграций. Сначала зафиксируйте:
- Цель сайта и главное действие посетителя: заявка, покупка, запись, запрос коммерческого предложения.
- Типы страниц: главная, услуги, категории, карточки, кейсы, статьи, служебные страницы.
- Источники контента и ответственного за тексты, фотографии, характеристики и перевод.
- Интеграции: CRM, склад, платежи, аналитика, телефония, рассылки. Для каждой укажите систему и направление обмена.
- Обязательные ограничения: сроки, языки, доступность, роли сотрудников, требования к размещению данных.
- Существующий сайт и URL, которые нужно сохранить или перенести.
Для корпоративного проекта можно взять за основу шаблон технического задания. Он помогает отделить обязательный объем первой версии от функций, которые можно добавить позже.
Как проверить портфолио и команду
Портфолио показывает внешний результат, но не раскрывает роль исполнителя. Попросите по двум-трем похожим проектам объяснить, какие части команда разработала сама, какие интеграции внедрила и кто поддерживает сайт после запуска. Откройте проекты на телефоне: проверьте навигацию, формы, скорость загрузки и доступность ключевых страниц.
Спросите, кто будет вести проект ежедневно: руководитель проекта, разработчик, дизайнер, редактор, специалист по поиску. Имена в презентации не заменяют указания ролей в плане работ. Если работу передают субподрядчику, зафиксируйте ответственность перед вами.
| Что спросить | Какой ответ нужен для решения |
|---|---|
| Покажете проект с похожим каталогом, кабинетом или интеграцией? | Ссылка на работающий результат и объяснение объема выполненных работ |
| Кто утверждает структуру и прототипы? | Назначенный ответственный с вашей и исполнительской стороны |
| Где смотреть промежуточную версию? | Тестовый контур и порядок демонстраций |
| Как фиксируются изменения объема? | Процедура оценки, согласования стоимости и сроков |
| Кто исправляет ошибки после запуска? | Срок реакции, границы гарантии и канал обращения |
Отсутствие публичного кейса иногда объясняется конфиденциальностью клиента. Тогда попросите обезличенное описание задачи, демонстрацию допустимых экранов или технический разбор без чужих данных.
Как сравнить сметы, если суммы различаются
Для подробной проверки используйте таблицу сравнения смет на сайт: в ней отдельно учтены контент, интеграции, приемка и регулярные расходы.
Разбейте каждое предложение на одинаковые блоки. Если подрядчик включил контент и тестирование, а другой оставил их за заказчиком, итоговые цены пока нельзя сравнивать напрямую.
| Блок | Что должно быть указано в смете |
|---|---|
| Проектирование | Карта страниц, пользовательские сценарии, прототипы, список требований |
| Дизайн | Число уникальных шаблонов и адаптивных состояний, порядок согласования |
| Разработка | Функции, интеграции, админка, роли пользователей, тестовая среда |
| Контент и перенос | Кто пишет и загружает материалы, какие URL и данные переносятся |
| Проверка и запуск | Сценарии тестирования, исправление ошибок, настройка аналитики, план переключения |
| Поддержка | Что входит после релиза, стоимость дополнительных работ, сроки реакции |
Попросите назвать допущения оценки: например, «до трех типов карточек», «одна CRM», «контент предоставляет заказчик». Любое допущение, не соответствующее вашему проекту, меняет итоговую стоимость. Отдельно сравните расходы владения: хостинг, лицензии, платные расширения, резервные копии и поддержку. Для оценки масштаба работ пригодится разбор стоимости корпоративного сайта.
Какие права и доступы закрепить до начала работ
Проверьте договор и приложения с юристом: кто владеет доменом, аккаунтом хостинга, репозиторием, макетами, текстами и созданным кодом; какие лицензии на сторонние компоненты используются; что именно передается при приемке. Техническая часть передачи должна быть перечислена отдельно: исходники, инструкция по запуску, учетные записи, доступ к аналитике, резервная копия и перечень внешних сервисов.
У заказчика должен быть собственный административный доступ к домену и значимым сервисам. Рабочий доступ подрядчика можно выдать отдельно с необходимыми правами. Это упрощает смену команды и восстановление сайта, если сотрудничество закончится.
Что спросить про SEO до разработки
Поисковая доступность зависит от структуры и реализации сайта. Попросите показать, где в плане работ находятся карта URL, заголовки страниц, внутренние ссылки, sitemap, canonical, редиректы при переносе и проверка индексации после запуска. Если сайт меняет адреса, должна быть таблица соответствия старых и новых URL.
Google рекомендует обычные ссылки <a href> для обнаружения страниц и понятный текст ссылок. Его рекомендации по заголовкам требуют описательных и кратких названий страниц. Поэтому попросите показать не обещание «SEO включено», а примеры шаблонов страницы и маршрут к важным материалам.
Ни одна студия не может обещать определенную позицию или отсутствие колебаний трафика после запуска. Проверяемое обязательство — корректно реализовать согласованные требования и устранить выявленные ошибки.
Как принять сайт и не потерять управление после релиза
До разработки согласуйте приемку по сценариям: отправить форму, оформить заказ, найти страницу, войти в кабинет, проверить обмен с CRM, открыть сайт на телефоне. Для каждого сценария укажите ожидаемый результат. Ошибки записывайте с адресом страницы, шагами воспроизведения и приоритетом.
Перед переключением на новый сайт получите резервную копию и план возврата к прежней версии. После запуска проверьте ключевые URL, формы, события аналитики, sitemap и ответы сервера. Если текущий сайт получает трафик, используйте отдельный план миграции корпоративного сайта.
Как передать действующий сайт новому подрядчику
Если вы выбираете команду для работающего сайта, добавьте к сравнению предложений отдельный этап передачи. Получение архива и приглашения в хостинг еще не подтверждает, что новая команда сможет восстановить сайт, выпустить изменение и обслуживать интеграции. Согласуйте результаты этого этапа до завершения работы прежнего исполнителя.
Паспорт передачи в начале статьи помогает собрать перечень систем и проверок. Для каждой строки укажите владельца аккаунта, технического ответственного, дату продления и ссылку на подтверждение. Пароли, токены, содержимое заявок и персональные данные в общей таблице не размещайте. Название учетной записи и способ безопасно получить доступ согласуйте отдельно.
| Что передать | Что должна проверить новая команда |
|---|---|
| Домен, DNS и сертификат | Заказчик управляет учетной записью; известны записи, сроки продления и порядок обновления сертификата |
| Хостинг и инфраструктура | Известны размещение сайта, необходимые сервисы и ответственные; доступ позволяет выполнить согласованные действия |
| Исходники и инструкция запуска | Подтверждена версия работающего сайта; копию можно собрать и запустить в отдельной среде |
| База данных, загруженные файлы и резервные копии | Согласованная копия восстанавливается; известны дата копии и данные, которые появились после нее |
| CMS, макеты и лицензии | Редактор может изменить материал; понятны условия использования компонентов и продления |
| Формы и интеграции | Тестовое обращение дошло до согласованного получателя; обмен с внешними системами проверен |
| Аналитика и поисковые кабинеты | Заказчик сохраняет управление; известны счетчики, ресурсы и ответственные |
| Выпуск и поддержка | Определены способ публикации, условия возврата, канал обращений и незакрытые дефекты |
Для WordPress резервная копия должна включать файлы и базу данных: это две отдельные части сайта. Официальная инструкция WordPress описывает их раздельно. Наличие архива файлов без базы не подтверждает возможность полного восстановления.
В каком порядке проверить передачу
- Соберите перечень систем, владельцев и сроков продления. Отметьте отсутствующие доступы и документы как непроверенные.
- Подготовьте согласованную резервную копию. Новая команда восстанавливает ее в отдельной среде; реальные рассылки, платежи и передачу заявок из тестовой копии отключают или направляют в тестовые системы.
- Проверьте работу редактора, выбранных страниц, форм и интеграций. Зафиксируйте шаги, ожидаемый результат и подтверждение проверки.
- Проведите согласованный пробный выпуск небольшого изменения в тестовой среде и проверку возврата к прежней версии. Возможность открыть сайт не заменяет проверку публикации.
- Определите момент передачи ответственности и порядок переноса последних изменений. У сайта с заказами или заявками данные после создания копии требуют отдельного учета.
- После приемки пересмотрите доступы прежней команды: отключите ненужные учетные записи и замените общие секреты, если они использовались. Проверьте, что новые настройки не нарушили работу сайта и обмена.
Сохраните список исключений: недоступный сервис, отсутствующая лицензия, непроверенный импорт или известная ошибка не должны получить статус «передано» без подтверждения. Для каждой проблемы назначьте ответственного и следующий шаг. Формат и сроки приемки определяются договоренностями сторон; этот технический список их не заменяет.
Если при смене команды также меняется CMS, хостинг или структура URL, дополнительно используйте план миграции сайта. При передаче сопровождения без такого переезда основной результат — способность новой команды поддерживать и выпускать действующий проект.
Чек-лист для короткого списка подрядчиков
- Все команды получили одинаковое задание и назвали допущения оценки.
- В предложениях перечислены этапы, результаты и ответственные.
- Показан релевантный работающий проект и роль исполнителя в нем.
- Указано, какие материалы и доступы предоставляет заказчик.
- Согласованы права на код, домен, макеты и контент.
- Описаны тестирование, приемка, запуск и порядок исправления ошибок.
- Указаны расходы на лицензии, хостинг и поддержку.
- Для действующего сайта есть план сохранения и переноса URL.
Если после этой проверки остаются два сопоставимых предложения, проведите с командами встречу по одному сложному сценарию вашего проекта. Разбор реального ограничения дает больше информации, чем общая презентация технологий. Для независимой оценки задания и рисков можно обратиться за IT-консультацией.
Разработка сложного веб-проекта
От идеи до масштабируемого кода. Оставьте заявку на предварительную оценку вашего проекта (смета и сроки).
FAQ
Достаточно получить архив сайта и доступ к хостингу?
Попросите новую команду восстановить согласованную копию и показать выпуск изменения в отдельной среде. Дополнительно нужны исходники, база данных, загруженные файлы, настройки внешних сервисов и инструкция запуска в составе, соответствующем вашему проекту.
Когда отключать доступ прежнего подрядчика?
Согласуйте момент завершения работ и передачи ответственности. После подтвержденной приемки пересмотрите ненужные доступы и общие секреты. При выявленной угрозе безопасности порядок ограничения доступа требует отдельного решения; обычная передача не должна оставлять сайт без управляющей команды.
Нужно ли менять платформу при смене разработчика?
Смена команды сама по себе не требует замены CMS или фреймворка. Сначала проверьте возможность поддержки, выпуска и восстановления действующего проекта. Миграцию оценивайте отдельно, если подтверждены ограничения платформы или новые требования.