Выбор подрядчика
Как выбрать подрядчика на разработку сайта
Сильный подрядчик объясняет не только что сделает, но и как проверит результат, что не входит в цену и какие риски нужно снять до разработки.
Коротко
Выбирайте подрядчика на разработку сайта по семи признакам: он понимает бизнес-задачу, показывает релевантные рабочие кейсы, разделяет проект на проверяемые этапы, раскрывает состав и исключения сметы, фиксирует критерии приёмки, передаёт права и критичные доступы, а также заранее описывает запуск и поддержку. Сравнивайте не общую цену, а одинаковый объём сценариев и результатов.
Сначала проверьте понимание задачи
Подрядчик должен уметь пересказать задачу через результат бизнеса и действие пользователя. Если разговор сразу уходит в цвет, CMS и количество страниц, команда ещё не поняла, зачем нужен продукт.
Хорошие вопросы касаются аудитории, текущего процесса, источника трафика, обработки заявки, интеграций, ограничений и критерия успеха. Для магазина важен путь заказа, для корпоративного сайта — сложность услуги и роль отдела продаж, для кабинета — частая операция пользователя.
Не требуется приносить готовое ТЗ. Подрядчик может предложить discovery или прототип как отдельный этап. Важно, чтобы результат этапа был передаваемым и понятным.
- Какую проблему должен решить сайт?
- Кто основной пользователь и что он делает?
- Как обращение или заказ обрабатывается после формы?
- Какие системы и данные нужно подключить?
- Что обязательно для первого релиза?
- По какой метрике будем проверять результат?
Проверяйте кейсы, а не только красивые обложки
Релевантный кейс объясняет исходную задачу, ограничения, решение и результат. Для сложного интерфейса полезно открыть рабочую демонстрацию и пройти путь пользователя. Статичный макет не показывает формы, ошибки, адаптив и административную логику.
Спросите, какую часть проекта делала команда: стратегию, дизайн, frontend, backend, SEO, контент или поддержку. Это особенно важно для проектов, где студия показывает известный бренд, но отвечала за один экран.
В портфолио ХЭМС можно открыть e-commerce Instrument Pro, онлайн-галерею LIRA, сайт Нечкино и продукт Stars Bot.
| Что проверить | Сильный сигнал | Красный флаг |
|---|---|---|
| Задача | Есть контекст и ограничения | Только название и картинка |
| Роль команды | Перечислена зона ответственности | Непонятно, что сделано |
| Интерфейс | Можно пройти сценарий | Только первый экран |
| Результат | Конкретное изменение или рабочая функция | Абстрактный «рост бренда» |
| Стек | Объяснён выбор | Список технологий без связи с задачей |
Сравнивайте одинаковый состав, а не итоговую цифру
Две оценки с разницей в несколько раз могут описывать разные продукты. В одной — шаблон, пять блоков и форма. В другой — исследование, прототип, индивидуальный дизайн, адаптивы, CMS, интеграции, тестирование и запуск.
Попросите разбить смету по этапам и назвать исключения. Домен, сервер, лицензии, платные сервисы, контент, массовое наполнение и рекламный бюджет часто оплачиваются отдельно.
Слишком ранний фикс без вопросов обычно означает большой запас или будущие доплаты. Для неизвестных интеграций разумнее отдельный аудит или диапазон с условиями уточнения.
| Раздел сметы | Что должно быть видно | Контроль |
|---|---|---|
| Проектирование | Сценарии, структура, прототип | Как принимается результат |
| Дизайн | Страницы, состояния, адаптивы | Сколько концепций и циклов |
| Разработка | Frontend, backend, CMS, интеграции | Какие функции входят |
| Тестирование | Устройства, браузеры, ошибки | Критерии готовности |
| Запуск | Домен, аналитика, формы, передача | Кто и что проверяет |
| Поддержка | Срок, канал, гарантия, SLA | Что считается новой задачей |
Процесс должен показывать результат по ходу проекта
Не соглашайтесь на несколько месяцев невидимой работы до финальной презентации. После каждого этапа нужен артефакт: карта задачи, прототип, дизайн, тестовый стенд, отчёт проверки или опубликованный релиз.
Уточните, кто принимает решения и где фиксируются комментарии. Один ответственный со стороны клиента ускоряет согласование. Подрядчик должен заранее сообщать влияние новой функции на срок и стоимость.
Промежуточный стенд позволяет проверять реальный адаптив и интеграции, а не обсуждать их по скриншоту. Репозиторий и история изменений важны для дальнейшей поддержки.
- БрифКоманда фиксирует задачу, ограничения и первый измеримый результат.
- ПланПоявляются границы, этапы, стек, риски и точки контроля.
- Прототип и дизайнСценарии проверяются до дорогой разработки.
- СборкаКлиент видит промежуточные версии на тестовом адресе.
- ПриёмкаРезультат проверяется по согласованным критериям.
- ЗапускПередаются доступы, документация и формат поддержки.
Зафиксируйте права, доступы и приёмку
В договоре и приложениях должны быть предмет, этапы, сроки, цена, порядок изменений, критерии приёмки, переход прав, гарантия и состав передачи. Общая формулировка «сайт под ключ» не защищает стороны.
Критичные аккаунты — домен, DNS, сервер, аналитика, платёжный кабинет — лучше оформлять на компанию клиента. Подрядчик получает необходимые роли. Репозиторий, CMS и документация передаются в согласованном объёме.
Проверьте сторонние лицензии и регулярные платежи. Шрифт, модуль, изображение или SaaS не становятся собственностью клиента только потому, что используются на сайте.
Десять вопросов подрядчику до выбора
Ответы должны быть конкретными и связанными с вашей задачей. Универсальное обещание «сделаем быстро и качественно» не показывает способ управления риском.
После разговора попросите коротко зафиксировать понимание проекта, первый этап и открытые вопросы. Это покажет качество коммуникации лучше длинной презентации.
Описание процесса ХЭМС опубликовано на странице работы над проектом, ориентиры — в прайсе, а направления — в каталоге услуг.
- Как вы поняли задачу и главный пользовательский сценарий?
- Что будет результатом первого этапа?
- Какие риски вы видите сейчас?
- Какие работы и расходы не входят в оценку?
- Как выглядит промежуточная версия и как часто её показывают?
- Как оцениваются новые пожелания?
- Кому принадлежат код, дизайн и доступы?
- Как проверяются формы, интеграции и мобильная версия?
- Что происходит после запуска?
- Кто будет отвечать за проект со стороны подрядчика?
Выбирайте не обещание идеального результата, а команду, которая умеет превращать неопределённость в проверяемые этапы и заранее показывает границы.
FAQ
Частые вопросы
01Нужно ли выбирать самую дешёвую смету?
Нет. Сначала приведите предложения к одинаковому составу. Дешёвая оценка может не включать проектирование, адаптивы, CMS, интеграции, тестирование или запуск.
02Что лучше: фрилансер или студия?
Зависит от объёма и риска. Для узкой задачи подходит один специалист. Для проекта со стратегией, дизайном, frontend, backend, SEO и поддержкой нужна команда и единая ответственность.
03Можно начать с небольшого этапа?
Да. Аудит, discovery, прототип или техническое исследование позволяют проверить коммуникацию и получить передаваемый результат до большого договора.
04Как понять, что кейс реальный?
Попросите показать рабочий интерфейс, процесс, конкретную роль команды и детали решений. Не требуйте раскрывать конфиденциальные данные клиента.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Начните с разбора задачи
Покажем первый этап, риски, ориентир по сроку и состав команды. Большое ТЗ для разговора не требуется.