Выбирать разработчика сайта стоит по тому, насколько понятно он превращает задачу в проверяемый план. До договора попросите показать ход работы, состав результата, правила изменений и способ приёмки. Портфолио помогает начать разговор, но само по себе не отвечает, кто будет принимать решения, как устроены сроки и что останется у заказчика после запуска.
Сначала определите, кого именно ищете
Словом «разработчик» называют фрилансера, студию, агентство и команду из нескольких специалистов. Сравнивайте роли, а не названия: кто собирает требования, проектирует структуру, отвечает за дизайн и код, готовит контент, проверяет результат и координирует работу.
Один специалист может быть подходящим выбором для небольшого проекта с готовой структурой и ограниченным набором функций. Для личного кабинета, нескольких интеграций или каталога с данными понадобятся разные компетенции либо партнёры; важно заранее понимать, кто отвечает за общий результат.
Проверяйте не картинку, а близость задачи
Попросите показать два-три проекта, похожих по устройству на ваш: например, по наличию каталога, фильтра, личного кабинета или обмена данными. Уточните, что именно делал кандидат, какие ограничения были у проекта и как принимали результат.
Если нельзя раскрыть клиента или цифры, достаточно обезличенного описания своей роли и решения. Не требуйте закрытую информацию, но просите отделить собственный вклад от работы всей команды. Особенно полезно посмотреть не только главную страницу, но и мобильный вид, формы, карточки, состояния ошибок и доступные способы связи.
Задайте одинаковые вопросы каждому кандидату
Используйте одну и ту же короткую форму на первой встрече. Ответы можно заносить в таблицу и сравнивать без попытки угадать, кто «понравился больше».
| Что проверить | Вопрос кандидату | Хороший признак |
|---|---|---|
| Понимание задачи | Что нужно выяснить до сметы? | Называет неизвестные и предлагает способ их закрыть |
| Состав команды | Кто отвечает за аналитику, дизайн, разработку и запуск? | Роли и ответственный за связь названы конкретно |
| Оценка | Какие допущения заложены в срок и стоимость? | Исключения и зависимости записаны, а не скрыты в общей сумме |
| Коммуникация | Где смотреть этапы, вопросы и согласования? | Есть единое место фиксации решений и понятный ритм связи |
| Приёмка | По каким критериям готова каждая функция? | Критерии можно проверить на тестовой версии |
| Передача | Какие доступы и материалы получит заказчик? | Обсуждаются домен, код, документация и инструкции |
| Поддержка | Что происходит при ошибке после запуска? | Разделены гарантия, развитие и регулярное обслуживание |
Это не рейтинг с универсальными весами. Если вам важнее интеграция, подробно проверяйте план работы с данными; если сайт должен редактировать внутренний сотрудник — покажите, как устроено управление контентом.
Как читать смету и сроки
Смета должна называть работы и результаты, которые можно проверить. Слова «дизайн», «разработка» и «SEO» без состава задач не позволяют понять, что включено. Попросите вынести отдельно число шаблонов, функции, материалы, интеграции, проверку, перенос и поддержку.
Срок тоже зависит от участия заказчика. Если тексты, доступы к CRM или согласования предоставляет ваша команда, укажите, кто и когда это сделает. Попросите показать зависимости между этапами и порядок действий при задержке внешней системы или обратной связи.
Для сравнения цен сначала подготовьте одинаковые требования: пригодится гайд о стоимости и составе сметы и чек-лист ТЗ для сайта.
Уточните права, доступы и передачу результата
До старта договоритесь, на чьё имя зарегистрированы домен и ключевые аккаунты, где хранится исходный код и как заказчик получает доступы. Уточните, какие материалы создаются специально для проекта, какие сторонние библиотеки или сервисы используются и какие платежи за них продолжаются.
При завершении проекта запросите исходники, инструкцию по развёртыванию и редактированию, перечень интеграций, список учётных записей и список известных ограничений. Конкретный состав зависит от договора и выбранной платформы; зафиксируйте его до начала, чтобы не выяснять на этапе передачи.
Признаки, при которых стоит остановиться и уточнить
- Кандидат обещает точную сумму и срок до того, как услышал задачу.
- В предложении нет исключений, а дополнительные работы никак не описаны.
- Непонятно, кому принадлежат аккаунты, код и материалы после оплаты.
- Портфолио не позволяет понять личный вклад кандидата.
- Приёмка описана словами «всё будет работать», без перечня сценариев.
- Поддержка смешана с гарантийными исправлениями и развитием продукта.
- Доступ к специалисту зависит от одного канала или устных договорённостей.
Каждый пункт сам по себе не доказывает, что исполнитель ненадёжен. Это причина задать конкретный вопрос и попросить ответ зафиксировать письменно.
Простая проверка перед решением
Перед выбором проведите короткий рабочий этап: передайте бриф, попросите состав работ и проведите встречу по одному сценарию пользователя. Сравните, какие вопросы задал кандидат, что он предположил и какие риски назвал. Так виден ход мысли, который не покажет красивый макет.
Если требования пока не собраны, начните с разработки сайта для бизнеса и обсуждения этапа проектирования. Хорошее предложение помогает понять следующий шаг, даже если окончательная оценка появится после уточнения деталей.
Короткий ответ
Выбирайте разработчика, который умеет объяснить состав команды, допущения сметы, критерии приёмки и передачу результата простыми проверяемыми словами. Сравните несколько предложений на одном брифе, задайте одинаковые вопросы и зафиксируйте договорённости до оплаты. Портфолио учитывайте как подтверждение релевантного опыта, а не как замену плану работ.
Ведущий инженер и разработчик веб-систем. Специализируется на Next.js, чистой архитектуре, Core Web Vitals и алгоритмическом ранжировании.
