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

Выбирать разработчика сайта только по портфолио и итоговой цене рискованно. За похожими предложениями могут скрываться разные работы: в одном случае исполнитель подготовит структуру, настроит формы и проверит интеграции, в другом — соберёт страницы из предоставленных материалов. Чтобы сравнить подрядчиков, нужно разобраться в составе проекта, порядке работы и том, что вы получите после запуска.

Разработка влияет на удобство и работоспособность сайта, но сама по себе не гарантирует поток клиентов. Обращения зависят также от предложения, источников посетителей и обработки запросов. Хороший признак — когда подрядчик объясняет свою зону ответственности, задаёт вопросы о бизнесе и предлагает проверяемый результат.

1. Опишите задачу до запроса стоимости

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

Подготовьте короткое описание:

• Предложение: какие услуги или товары нужно представить.
• Пользовательский сценарий: оставить запрос, выбрать товар, рассчитать стоимость, оформить заказ или получить информацию.
• Источники посетителей: реклама, поиск, рекомендации, существующая клиентская база.
• Материалы: тексты, фотографии, каталог, фирменный стиль и примеры работ.
• Связанные системы: используемые CRM, учётная программа, сервисы оплаты и доставки, если они нужны проекту.
• Ограничения: ориентир по бюджету, желаемая дата запуска и планы развития.

Например, «нужен современный сайт» — слишком общее описание. Конкретнее: «нужен каталог оборудования с характеристиками, запросом расчёта и передачей обращения ответственному менеджеру». По такой задаче проще обсуждать структуру и оценивать объём работ.

2. Проверьте опыт на похожих задачах

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

Совпадение отрасли полезно, но не обязательно. Для сложного каталога может быть важнее опыт работы с фильтрами и характеристиками, а для обмена с 1С — понимание состава данных и правил синхронизации.

Что уточнить по кейсу:

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

Если в кейсе указан рост заявок или продаж, спросите, за какой период он измерен и какие ещё изменения происходили: например, запуск рекламы или расширение ассортимента. По одной цифре нельзя определить вклад разработки.

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

3. Сравните состав предложений, а не только цену

Формулировка «сайт под ключ» не объясняет, кто пишет тексты, наполняет каталог, покупает лицензии и настраивает аналитику. До выбора исполнителя попросите перечислить включённые работы, ограничения и отдельные расходы.

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

4. Узнайте, почему предлагается именно эта платформа

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

Полезные вопросы:

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

Например, для сайта на 1С-Битрикс стоит заранее согласовать редакцию, используемый шаблон, модули и индивидуальные доработки. Существенные ограничения должны быть понятны до начала работ, а расходы на необходимые лицензии — отражены в оценке.

Если сайт уже существует, попросите сравнить доработку и полную переработку. Новый проект может быть оправдан, но причины должны быть конкретными: неподходящая структура, технические ограничения или несоразмерный объём исправлений. Иногда достаточно доработать действующий сайт.

5. Обсудите формы, интеграции и проверку обращений

Работа формы не заканчивается сообщением «Спасибо». Нужно определить, где сохраняется запрос, кто получает уведомление и как проверяется доставка. При использовании CRM — какая запись создаётся, какие данные передаются и кто отвечает за дальнейшую обработку.

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

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

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

6. Согласуйте этапы, обратную связь и изменения

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

Например, работа может включать:

1. уточнение задач и состава проекта;
2. согласование структуры и прототипов;
3. подготовку и согласование дизайна;
4. разработку функций и интеграций;
5. наполнение и тестирование;
6. запуск и передачу материалов.

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

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

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

7. Заранее определите, как будете принимать сайт

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

• Форма: посетитель отправляет данные, запрос сохраняется и доходит до получателя.
• Каталог: поиск и фильтры позволяют найти товары по согласованным параметрам.
• Заказ: покупатель выбирает товары, видит итоговую сумму и завершает оформление.
• Редактирование: сотрудник меняет текст, цену или изображение через предусмотренный интерфейс.
• Мобильная версия: основные сценарии доступны на согласованных устройствах и разрешениях.
• Интеграции: тестовые данные корректно проходят между системами.

Если важны скорость или нагрузка, нужны конкретные условия измерения и согласованные показатели. Формулировку «сайт должен летать» невозможно одинаково трактовать при сдаче.

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

8. Обсудите передачу проекта и работу после запуска

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

Согласуйте состав передачи:

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

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

Обсудите, как сообщать об ошибках после запуска, в какие сроки исполнитель реагирует и какие работы оплачиваются отдельно. Поддержка может быть разовой или регулярной. Главное — понятные условия, особенно если сайт принимает заказы и связан с внешними системами.

Фрилансер или студия: кого выбрать

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

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

Какие ответы стоит уточнить до выбора

• «Заявки гарантированы». За счёт каких источников, бюджета и условий планируется результат? Что именно берёт на себя исполнитель?
• «Все интеграции включены». Какие системы, данные и сценарии имеются в виду?
• «SEO входит». Это технические настройки, подготовка структуры и текстов или дальнейшее продвижение?
• «Любые правки бесплатно». Как ограничен объём и что считается новой задачей?
• «Всё будет на наших аккаунтах». Как заказчик получит управление и что произойдёт после завершения сотрудничества?
• «Проще всё переделать». Какие проблемы текущего сайта обнаружены и почему доработка не подходит?

Одна неудачная формулировка ещё не повод отказываться от сотрудничества. Посмотрите, готов ли подрядчик конкретизировать ответ и зафиксировать договорённости. Если после обсуждения остаются существенные неопределённости по объёму, доступам и приёмке, сравнивать предложение с другими будет сложно.

Короткий список вопросов для первого разговора

1. Какие данные нужны вам, чтобы оценить мой проект?
2. Какие похожие задачи вы решали и что выполняли лично?
3. Что входит в стоимость, а что оплачивается отдельно?
4. Почему вы предлагаете эту платформу и какие у неё ограничения?
5. Кто готовит контент и наполняет сайт?
6. Как проверяются формы, заказы и необходимые интеграции?
7. Как согласуются этапы и дополнительные работы?
8. По каким критериям принимается результат?
9. Какие доступы и материалы я получу после запуска?
10. Как организованы исправление ошибок и дальнейшая поддержка?

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

Частые вопросы

Нужно ли сначала заказывать подробное техническое задание?

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

Можно ли выбрать подрядчика без кейсов в моей отрасли?

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

Должен ли разработчик гарантировать продажи?

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

Обязательно ли заказывать постоянную поддержку?

Нет. Можно договориться о разовых работах. Но заранее определите, кто следит за техническим состоянием, резервными копиями и необходимыми обновлениями, а также к кому обращаться при сбое.

Что делать, если текущий подрядчик предлагает только новый сайт?

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