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

Содержание статьи
До первого созвона
Сначала определите задачу, потом ищите исполнителя
Выбор подрядчика на разработку сайта начинается не с просмотра рейтингов и не с вопроса о технологии. Сначала компании нужно понять, какой рабочий результат она хочет получить. Один и тот же запрос «нужен новый сайт» может означать презентацию компании, сбор обращений, каталог, онлайн-продажи или личный кабинет.
Подготовьте короткое описание на одну–две страницы. Укажите цель, аудиторию, важные сценарии, имеющиеся материалы, интеграции и ограничения. Если структура пока неясна, используйте наш чек-лист технического задания. Это не заменяет аналитику, но позволяет получать сопоставимые предложения.
Цель проекта
Какое изменение должен дать сайт: больше подходящих обращений, понятная презентация услуг, прямые продажи или разгрузка команды.
Пользователи
Кто приходит на сайт, с каким вопросом, что должен увидеть и какое действие выполнить.
Границы
Какие страницы, функции и интеграции обязательны в первой версии, а что можно отложить.
Условия работы
Кто готовит контент, кто согласует решения, какие системы и доступы уже есть у компании.
Фрилансер, студия или продуктовая команда: кого выбирать
Формат исполнителя сам по себе не гарантирует результат. Важнее соответствие масштабу проекта, доступность нужных компетенций и понятная ответственность. Небольшой сайт может качественно сделать один опытный специалист. Сложному сервису понадобятся аналитика, дизайн, разработка, тестирование и DevOps.
| Формат | Когда подходит | Что проверить |
|---|---|---|
| Фрилансер | Небольшая задача с ясными границами и минимумом интеграций | Личное участие, резерв на случай недоступности, передача файлов и поддержка |
| Веб-студия | Сайт с несколькими дисциплинами и параллельной работой специалистов | Кто входит в команду, кто ведёт проект и кто реально выполнял показанные кейсы |
| Продуктовая команда | Веб-приложение или развиваемый сервис с гипотезами и регулярными версиями | Процесс приоритизации, аналитика, архитектура, релизы и поддержка после запуска |
Не стремитесь купить максимальный состав команды. Для сайта-визитки сложный управленческий контур будет лишним. Для интернет-магазина отсутствие аналитика, тестирования и опыта интеграций создаёт риск уже после начала работ.
Проверка опыта
Как оценить портфолио и кейсы разработчика
Портфолио показывает визуальный уровень, но почти ничего не говорит о процессе и техническом результате. Откройте рабочие сайты, а не только изображения в презентации. Проверьте мобильную версию, формы, навигацию и скорость отклика интерфейса.
Какую проблему решал проект?
Что именно делала команда?
Почему выбрана такая структура?
Что изменилось после запуска?
Как сайт работает сегодня?
Релевантность важнее известности клиента. Если вам нужен корпоративный сайт со сложным каталогом, полезнее кейс с похожими данными и процессами, чем эффектная промостраница из другой отрасли. Попросите показать административную часть, поведение ошибок и пример адаптива — эти детали редко попадают в публичную подборку.
Уточните, кто создавал кейс. Студия могла отвечать только за дизайн, а разработку выполняла другая команда. Это нормально, если роли названы честно. Проблема возникает, когда чужая работа выдаётся за подтверждение собственной компетенции.
Какие вопросы задать разработчику сайта на первой встрече
Сильная встреча — не презентация подрядчика, а совместный разбор задачи. Хороший кандидат задаёт вопросы об аудитории, продажах, контенте, текущих системах и способе принятия решений. Если разговор сразу сводится к цвету кнопок и CMS, бизнес-контекст пока не исследован.
О результате
Как вы поняли нашу задачу? Какие риски видите? Что предлагаете проверить до дизайна и разработки?
О процессе
Какие будут этапы, демонстрации и точки согласования? Кто отвечает на вопросы и как фиксируются решения?
О команде
Кто конкретно будет работать над проектом? Какой у специалистов опыт в похожих задачах?
О качестве
Как проверяются мобильная версия, формы, доступность, безопасность, скорость и поисковая готовность?
Об изменениях
Что произойдёт, если во время проекта появится новая функция? Как оценивается её влияние?
О передаче
Какие доступы, файлы, инструкции и права получит компания после запуска?
Оценивайте не только содержание ответа, но и форму. Если техническое решение нельзя объяснить понятным языком, в проекте будет сложно принимать решения. Подрядчик не обязан соглашаться со всеми пожеланиями, но должен аргументировать ограничения и предлагать альтернативу.
Письменные договорённости
Что проверить в предложении и договоре
Качественное предложение связывает исходную задачу с составом работ. В нём нет необходимости перечислять каждую мелкую кнопку, но должны быть зафиксированы границы проекта, этапы, результаты и зона ответственности сторон.
| Раздел | Что должно быть понятно | Почему это важно |
|---|---|---|
| Состав результата | Страницы, функции, адаптив, интеграции и материалы | Убирает разные трактовки слова «сайт» |
| Этапы | Что и когда демонстрируется, кто согласует | Позволяет увидеть проблему до финала |
| Приёмка | По каким критериям проверяется готовность | Заменяет субъективное «нравится — не нравится» |
| Изменения | Как новые требования влияют на объём и сроки | Не даёт проекту бесконтрольно разрастаться |
| Права и доступы | Кому принадлежат код, дизайн, домен и аккаунты | Сохраняет управляемость после запуска |
| Поддержка | Что входит в гарантию, как принимаются обращения | Разделяет исправление ошибки и развитие продукта |
Обратите внимание на зависимости: тексты, фотографии, согласование юридических документов и доступы часто находятся на стороне заказчика. Ответственный подрядчик обозначает это заранее и не создаёт впечатление, что проект существует отдельно от вашей команды.
Как проверить техническое качество будущего сайта
Заказчику не нужно проводить техническое интервью. Достаточно попросить подрядчика описать стандарты качества и показать, как они проверяются. В разговоре должны появиться не только дизайн и функции, но и эксплуатация сайта после запуска.
Мобильная версия. Какие устройства и ширины проверяются, как работают меню, формы и длинный контент.
Производительность. Как команда контролирует загрузку, интерактивность и стабильность интерфейса. Для общего ориентира можно использовать Core Web Vitals.
Доступность. Есть ли клавиатурная навигация, заметный фокус, подписи полей и достаточный контраст. Базовые требования описывает стандарт WCAG.
Поисковая готовность. Семантическая структура, метаданные, индексируемость и понятные URL должны быть частью разработки. Полезная основа — Google Search Essentials.
Надёжность и безопасность. Обработка ошибок, резервные копии, обновления, защита форм и минимальные права доступов.
Аналитика. Какие целевые действия фиксируются, как проверяется передача событий и кто владеет аккаунтами.
Не требуйте максимальных показателей любой ценой. Попросите объяснить, какие показатели важны для вашего проекта, что влияет на них и как качество будет подтверждено перед запуском.
Сигналы риска
Красные флаги при выборе веб-студии или разработчика
Подрядчик уже выбрал платформу и структуру, хотя ещё не изучил процессы и ограничения.
Весь сайт обещают показать только в конце, без прототипа, демонстраций и ранней проверки сценариев.
Нет рабочих ссылок, роли команды неясны, а описание кейса состоит только из изображений.
Состав проекта, изменения и критерии готовности не фиксируются в едином документе.
Компания рискует потерять контроль над критичной цифровой инфраструктурой.
Не определены канал обращений, время реакции, гарантийные случаи и порядок обновлений.
Один сигнал ещё не доказывает проблему. Но сочетание нескольких признаков означает, что неопределённость переносится с этапа выбора внутрь проекта, где исправлять её сложнее.
Матрица оценки подрядчиков на создание сайта
Чтобы впечатление от яркой презентации не стало единственным аргументом, оцените кандидатов по единой шкале. Вес критерия можно менять под задачу, но формулировки должны оставаться одинаковыми для всех.
Команда связывает функции сайта с аудиторией, процессами и результатом бизнеса.
Есть проверяемые кейсы с похожей логикой, данными или интеграциями.
Понятны этапы, участники, демонстрации, приёмка и работа с изменениями.
Названы стандарты мобильности, скорости, доступности, SEO и безопасности.
Компания получает контроль над доступами и понятный порядок дальнейшей работы.
Поставьте каждому кандидату от одного до пяти баллов, умножьте на вес и добавьте короткий комментарий. Цифра не принимает решение за вас, но показывает, где оценка основана на фактах, а где — только на симпатии.
После выбора
Как провести спокойный старт проекта
Выбор разработчика завершён только тогда, когда команда одинаково понимает ближайший этап. Не передавайте сразу все доступы и не начинайте с обсуждения визуальных деталей. Организуйте короткий установочный процесс.
Один ответственный за решения со стороны бизнеса и один — со стороны подрядчика.
Зафиксировать первую версию, ожидаемые материалы и критерии результата.
Определить канал, ритм демонстраций и место хранения решений.
Создать отдельные учётные записи с минимальными необходимыми правами.
Согласовать структуру и прототип до детального дизайна и разработки.
Короткие ответы
Частые вопросы о выборе подрядчика
Как выбрать подрядчика на разработку сайта, если нет технического специалиста?
Сравнивайте не названия технологий, а понимание задачи, ясность этапов, релевантные кейсы, состав результата и способ приёмки. Хороший подрядчик объясняет решения простым языком и фиксирует договорённости письменно.
Сколько подрядчиков стоит сравнить?
Обычно достаточно короткого списка из трёх–пяти подходящих команд. Большая выборка создаёт много несопоставимых предложений, а слишком маленькая не показывает разницу в подходах.
Можно ли выбирать разработчика только по портфолио?
Нет. Красивый экран не показывает качество мобильной версии, скорость, админ-панель, интеграции и процесс работы. Портфолио нужно дополнять разбором задачи, демонстрацией работающего сайта и вопросами о роли команды.
Нужно ли отдавать подрядчику доступы в начале проекта?
Передавайте только необходимые доступы, отдельным пользователям и с минимальными правами. Критичные аккаунты, домен, аналитика и рекламные кабинеты должны оставаться под контролем компании.
Что должно остаться у заказчика после запуска?
Доступы, исходный код и репозиторий в согласованном объёме, макеты, домен, аналитика, инструкции, перечень интеграций, резервная копия и понятные условия поддержки.
Как понять, что предложение подрядчика реалистично?
В нём видны этапы, результат каждого этапа, зависимости от заказчика, критерии приёмки, допущения и порядок изменений. Обещание результата без уточняющих вопросов и границ проекта — повод запросить детали.
Материал прочитан
Вернуться к началуБесплатная консультация
Оставьте заявкуна бесплатную консультацию
Разберём задачу, предложим подходящий формат и обозначим следующие шаги — без навязчивых продаж.
Написать в TelegramОбычно отвечаем в течение рабочего дня


