Подрядчика по разработке сайта лучше проверять не по уверенности в голосе, красивым макетам и обещанию «сделаем под ключ», а по управляемости процесса. Сайт для бизнеса — это не картинка в браузере, а инструмент, который должен быть понятен владельцу, поддерживаем, готов к заявкам, аналитике, SEO-базе и дальнейшим изменениям.
Хорошая проверка не дает стопроцентной защиты от ошибок, но снижает риск получить сайт, который сложно развивать, продвигать, принимать и передавать другому специалисту.
Почему цены и портфолио недостаточно
Портфолио показывает внешний результат, но почти ничего не говорит о том, как проект был сделан. Сайт может выглядеть аккуратно, но внутри иметь хаотичную структуру, неудобную CMS, неработающие формы, отсутствие аналитики, технические ограничения и зависимость от одного исполнителя.
Цена тоже не является самостоятельным критерием. Два подрядчика могут назвать разные суммы, но включать в них разный объем работ. Один учитывает структуру, прототип, адаптив, CMS, базовые SEO-настройки, аналитику, тестирование и запуск. Другой подразумевает только дизайн и верстку нескольких страниц. Сравнивать такие предложения только по цене опасно: дешевле может оказаться не проект, а неполный состав работ.
По портфолио обычно не видно:
- как подрядчик собирал требования;
- кто отвечал за структуру сайта;
- продумывались ли сценарии пользователей;
- была ли заложена SEO-база;
- настраивались ли формы и аналитика;
- удобно ли заказчику редактировать контент;
- как сайт передавался после запуска;
- можно ли поддерживать проект без постоянной зависимости от первого разработчика.
Если сайт уже существует, но не дает ожидаемого эффекта, причина не всегда в рекламе или дизайне. Часто проблема лежит глубже: в структуре, офферах, технической базе, формах, аналитике или качестве посадочных страниц. Подробнее об этом — в материале «Почему сайт не приносит заявки».
Проверьте, как подрядчик выясняет задачу бизнеса
Сильный подрядчик начинает не с фразы «какой дизайн вам нравится», а с понимания задачи. Для одного бизнеса сайт нужен как источник заявок. Для другого — как презентация компании перед крупными клиентами. Для третьего — как каталог продукции, который помогает менеджерам в продажах. Для четвертого — как интернет-магазин с понятной логикой товаров, фильтров, оплаты и доставки.
От задачи зависит почти все: структура, количество страниц, функциональность, CMS, форма заявок, акценты в контенте, аналитика и дальнейшее развитие.
Насторожиться стоит, если подрядчик сразу предлагает решение, не задавая вопросов о бизнесе. Например: «вам нужен лендинг», «сделаем как у конкурента», «лучше всего интернет-магазин», «давайте сразу дизайн». Иногда это может быть предварительная гипотеза, но она должна проверяться вопросами.
Нормально, когда подрядчик уточняет:
- что именно продает или предлагает компания;
- кто принимает решение о покупке;
- какие продукты или услуги приоритетны;
- в каких регионах работает бизнес;
- откуда планируется трафик;
- как сейчас приходят заявки;
- какие возражения бывают у клиентов;
- какие действия пользователь должен совершить на сайте;
- кто будет обновлять сайт после запуска.
Хороший подрядчик не обязан знать вашу отрасль лучше вас. Но он должен понимать, какие вопросы влияют на структуру сайта и техническое решение.
Вопросы, которые стоит задать подрядчику
Перед стартом попросите объяснить:
- какую задачу должен решать сайт;
- какие ключевые сценарии пользователей он видит;
- какие страницы и разделы нужны на первом этапе;
- какие данные нужны от вас до проектирования;
- как структура сайта связана с заявками, продажами или работой отдела продаж;
- какие риски есть в задаче;
- что будет считаться нормальным завершением проекта.
Ответы не обязательно должны быть длинными. Важнее, чтобы они были конкретными. Если подрядчик говорит только общими фразами про «современный дизайн», «удобный интерфейс» и «эффективный сайт», но не связывает это с вашей задачей, стоит уточнять глубже.
Проверьте прозрачность состава работ
Фраза «разработка сайта под ключ» звучит удобно, но сама по себе ничего не фиксирует. Под ней могут понимать разные вещи: от сборки шаблона до полноценной разработки структуры, дизайна, CMS, интеграций, аналитики и запуска.
До начала работ нужно понять не только итог, но и путь к нему. Чем яснее состав проекта, тем меньше спорных ситуаций на приемке.
Попросите подрядчика разложить проект по этапам. Например:
- сбор требований;
- структура сайта;
- прототипы ключевых страниц;
- дизайн;
- адаптивные версии;
- верстка;
- настройка CMS;
- наполнение;
- интеграции;
- базовые SEO-настройки;
- аналитика;
- тестирование;
- перенос на основной домен;
- запуск;
- поддержка после релиза.
Не каждый проект требует всех этих этапов в полном объеме. Лендинг, сайт компании, каталог и интернет-магазин отличаются по сложности. Но подрядчик должен уметь объяснить, что именно входит в ваш проект, а что не входит.
До старта должно быть понятно:
- какие работы включены в стоимость;
- какие работы оплачиваются отдельно;
- кто готовит тексты, фотографии, товары и технические данные;
- какие страницы создаются;
- какая функциональность планируется;
- какая CMS или технология используется;
- как проходят согласования;
- как фиксируются правки;
- как принимается каждый этап;
- что происходит после запуска.
Если вам нужно понять, какие форматы работ вообще возможны — разработка с нуля, доработка, аудит, поддержка — можно посмотреть блок «Форматы работ».
Проверьте техническое решение: CMS, доступы, поддерживаемость
Техническая часть важна не ради терминов. Она влияет на то, сможете ли вы управлять сайтом, дорабатывать его, менять подрядчика, добавлять страницы, запускать новые услуги, обновлять каталог и подключать аналитику.
Подрядчик должен объяснить выбор CMS или технологии простым языком. Не обязательно превращать обсуждение в техническое собеседование. Владельцу бизнеса важны практические вопросы:
- почему выбрана эта CMS;
- подходит ли она под тип сайта;
- какие ограничения есть у решения;
- что можно будет редактировать без разработчика;
- как добавлять новые страницы;
- как менять тексты, изображения, услуги, товары;
- кто сможет поддерживать сайт после запуска;
- будут ли переданы доступы;
- что произойдет, если в будущем сменить подрядчика.
Опасный признак — когда подрядчик отвечает: «не волнуйтесь, мы все сделаем», но не объясняет, как будет устроен сайт. Еще хуже, если любое изменение возможно только через него, а система закрыта и непонятна. Иногда закрытые решения оправданы, но причины должны быть проговорены заранее.
Для лендинга может подойти одно решение. Для сайта компании с разделами, услугами, статьями и кейсами — другое. Для каталога или интернет-магазина важны уже другие критерии: структура товаров, фильтры, карточки, интеграции, управление остатками, SEO-возможности, скорость работы и удобство администрирования.
Проверяйте не модность технологии, а соответствие задаче и дальнейшей эксплуатации. О подходе к выбору платформ и CMS можно посмотреть в блоке «Технологии и CMS».
Красные флаги в технической части
Стоит задать дополнительные вопросы, если подрядчик:
- не может объяснить выбор CMS;
- говорит «мы всегда делаем только так» без связи с задачей;
- не обсуждает доступы;
- не показывает, как будет редактироваться контент;
- не говорит о резервных копиях;
- не объясняет, как сайт переносится или передается;
- обещает, что «любая доработка будет простой», но не раскрывает архитектуру;
- предлагает решение, где все изменения завязаны только на него.
Один такой признак не делает подрядчика плохим. Но сочетание нескольких повышает риск зависимости и технического долга.
Проверьте, учитывает ли подрядчик SEO-базу, аналитику и заявки
Сайт может быть опубликован и при этом плохо готов к работе как бизнес-инструмент. Например, страницы открываются, но формы не проверены, цели не настроены, метаданные отсутствуют, URL сформированы хаотично, мобильная версия неудобна, а владелец не понимает, откуда приходят заявки.
SEO-база — это не обещание позиций в поиске. Это нормальная подготовка сайта к индексации и дальнейшему продвижению: структура страниц, понятные адреса, заголовки, метаполя, технические настройки, корректные страницы услуг или категорий, отсутствие очевидных препятствий для поисковых систем.
Аналитика нужна не для красивых отчетов, а для управляемости. После запуска бизнес должен понимать, что происходит: какие страницы посещают, какие формы отправляют, где пользователи уходят, какие источники дают обращения. Без этого сложно принимать решения о доработках и рекламе.
До запуска нужно обсудить:
- какие базовые SEO-настройки входят в проект;
- как формируются URL;
- кто заполняет title и description;
- как устроены заголовки страниц;
- будут ли технические страницы;
- как проверяется мобильная версия;
- какие формы заявок есть на сайте;
- куда приходят уведомления;
- как тестируется отправка заявок;
- какая аналитика подключается;
- какие события или цели нужно отслеживать;
- кто получает доступы после запуска.
Если подрядчик говорит только о визуале и не обсуждает заявки, структуру страниц, формы, аналитику и базовые технические настройки, это риск. Не потому что каждый сайт обязан сразу идти в продвижение, а потому что без этих вещей сложнее понять, работает ли он после запуска.
Если сайт уже работает и есть ощущение, что часть обращений теряется, полезно отдельно разобрать путь пользователя. Об этом — в статье «Как найти места, где сайт теряет клиентов».
Проверьте процесс коммуникации
Даже технически сильный подрядчик может создать проблемы, если процесс непрозрачный. Для бизнеса риск не только в плохом коде, но и в хаосе: непонятно, что сейчас делается, кто за что отвечает, где зафиксированы решения, почему изменился объем работ и когда можно принимать этап.
До старта обсудите порядок коммуникации:
- где фиксируются задачи;
- кто отвечает со стороны подрядчика;
- кто принимает решения со стороны заказчика;
- как согласуются этапы;
- как передаются материалы;
- как обрабатываются правки;
- как фиксируются изменения в объеме работ;
- как подрядчик предупреждает о рисках;
- как часто показывает промежуточный результат.
Нормальный процесс не обязательно должен быть сложным. Для небольшого сайта достаточно понятных этапов, фиксированных договоренностей и регулярного показа результата. Для более сложного проекта потребуется более формальная постановка задач и приемка.
Плохой признак — когда все держится только на переписке без структуры. Сегодня договорились об одном, через неделю вспоминают другое, часть правок теряется, решения не фиксируются, а к финалу стороны по-разному понимают, что должно быть сделано.
Хороший подрядчик не просто выполняет задачи, а объясняет последствия решений. Например: если добавить новый раздел, это повлияет на структуру и сроки. Если изменить логику каталога, нужно пересмотреть фильтры. Если убрать часть контента, страница может хуже отвечать на вопросы пользователя. Такие предупреждения помогают бизнесу принимать осознанные решения.
Проверьте порядок приемки и запуска
Разработка сайта не заканчивается фразой «готово, можно смотреть». Финальный этап должен включать проверку, исправления, передачу доступов и понимание, что делать после запуска.
Приемка должна опираться на заранее согласованный состав работ. Если в начале не было структуры, перечня страниц, функциональности и критериев запуска, то в конце сложно определить, выполнен проект или нет. Начинаются субъективные споры: «мы думали, это входит», «а мы это не закладывали».
Перед запуском стоит проверить:
- основные страницы открываются корректно;
- меню и внутренние ссылки работают;
- формы отправляют заявки;
- уведомления приходят нужным людям;
- телефон, почта и мессенджеры указаны верно;
- сайт корректно отображается на мобильных устройствах;
- базовые SEO-поля заполнены или доступны для заполнения;
- адреса страниц выглядят понятно;
- аналитика подключена;
- цели или события проверены;
- CMS доступна ответственному сотруднику;
- типовые изменения можно внести без разработчика, если это было предусмотрено;
- доступы переданы;
- понятен порядок поддержки после запуска.
Особое внимание — формам заявок. Ошибка в отправке формы может быть незаметной для пользователя и болезненной для бизнеса. Сайт выглядит рабочим, реклама может идти, но обращения не доходят. Поэтому проверка отправки и уведомлений — не формальность.
После запуска почти всегда появляются мелкие правки: поправить текст, заменить изображение, добавить блок, уточнить форму, скорректировать мобильную версию. Это нормально. Лучше заранее обсудить, что входит в пострелизную поддержку, как ставятся задачи и как оцениваются новые доработки.
Если вы проверяете уже существующий сайт и думаете, менять подрядчика или переписывать все заново, не всегда стоит начинать с полного редизайна. Иногда безопаснее доработать текущий проект. Подробнее — в материале «Когда сайт лучше доработать, а не переписать».
Вопросы подрядчику перед договором
Чтобы сравнить нескольких исполнителей, полезно задавать одинаковые вопросы. Так проще увидеть разницу не только в цене, но и в подходе.
По задаче
- Как вы будете разбираться в нашем бизнесе перед началом работ?
- Какие данные нужны от нас?
- Как вы определяете структуру сайта?
- Какие пользовательские сценарии видите в нашей задаче?
- Какие риски можете назвать уже сейчас?
По составу работ
- Что входит в проект?
- Что не входит и оплачивается отдельно?
- Какие этапы будут?
- Что является результатом каждого этапа?
- Как принимаются этапы?
- Как фиксируются дополнительные пожелания?
По CMS и технологиям
- На какой CMS или технологии предлагаете делать сайт?
- Почему это подходит под нашу задачу?
- Какие ограничения есть у решения?
- Что мы сможем редактировать самостоятельно?
- Кто сможет поддерживать сайт после запуска?
- Как будут переданы доступы?
По SEO-базе и аналитике
- Какие базовые SEO-настройки входят в разработку?
- Как формируются URL и заголовки?
- Будут ли доступны поля title и description?
- Как подключается аналитика?
- Какие цели или события вы рекомендуете отслеживать?
- Как проверяются формы заявок?
По запуску и поддержке
- Как проходит финальная проверка?
- Что именно проверяется перед публикацией?
- Как сайт переносится на основной домен?
- Какие доступы мы получаем?
- Что происходит после запуска?
- Как оцениваются будущие доработки?
Ответы подрядчика должны быть понятны не только разработчику, но и владельцу бизнеса. Если для объяснения каждого решения используются только технические термины без перевода на бизнес-последствия, это усложнит управление проектом.
Красные флаги при выборе подрядчика
Красный флаг — не приговор, а повод задать уточняющие вопросы. Иногда причина в неудачной коммуникации, иногда — в реальном риске. Но если тревожных признаков много, лучше не торопиться с предоплатой и договоренностями.
Стоит насторожиться, если подрядчик:
- сразу называет цену без уточнения задачи;
- не спрашивает про бизнес, аудиторию и источники заявок;
- предлагает «сделать как у конкурентов» без анализа;
- не может описать этапы проекта;
- не фиксирует состав работ;
- избегает темы CMS и дальнейшей поддержки;
- не объясняет технические решения;
- не обсуждает доступы и передачу сайта;
- обещает заявки, продажи или позиции без оговорок;
- говорит только о дизайне и не обсуждает структуру;
- не упоминает аналитику и проверку форм;
- не показывает промежуточные результаты;
- не предупреждает об ограничениях;
- на конкретные вопросы отвечает общими фразами;
- переносит все решения «на потом».
Особенно опасна комбинация: нет четкого состава работ, нет понятной CMS, нет критериев приемки, нет обсуждения аналитики и передачи доступов. В такой ситуации даже визуально нормальный сайт может стать неудобным активом, который сложно развивать.
Как сравнивать нескольких подрядчиков
Если вы выбираете между студией, фрилансером и частным разработчиком, не стоит сравнивать только формат исполнителя. У каждого варианта могут быть сильные и слабые стороны. Гораздо полезнее сравнивать конкретный подход.
Оцените предложения по нескольким критериям:
- насколько подрядчик понял задачу;
- задавал ли вопросы о бизнесе;
- предложил ли понятную структуру работ;
- объяснил ли состав стоимости;
- обозначил ли ограничения;
- рассказал ли о CMS и поддержке;
- учел ли SEO-базу и аналитику;
- описал ли порядок приемки;
- готов ли передать доступы и документацию;
- понятно ли с ним общаться.
Если одно предложение заметно дешевле остальных, не нужно автоматически его исключать. Но стоит проверить, за счет чего цена ниже. Возможно, меньше страниц, нет CMS, нет наполнения, не включены адаптивные версии, не предусмотрена аналитика, не заложено тестирование или поддержка после запуска. Это не всегда плохо, если вы осознанно выбираете урезанный объем. Плохо, когда это выясняется в конце.
Если одно предложение заметно дороже, тоже стоит просить детализацию. Высокая цена должна быть связана с понятным объемом, уровнем проработки, сложностью функциональности, интеграциями, ответственностью и процессом, а не только с формулировкой «премиальная разработка».
Как проверить текущего подрядчика во время проекта
Иногда сомнения появляются уже после старта. Вроде работа идет, но нет ясности: что сделано, что осталось, почему меняются сроки, где фиксируются правки, каким будет итог.
В такой ситуации лучше не начинать с конфликта. Сначала стоит запросить управленческую картину проекта:
- текущий статус работ;
- список согласованных страниц;
- список готовых и незавершенных задач;
- ближайший результат, который можно проверить;
- перечень открытых вопросов со стороны заказчика;
- перечень рисков;
- план до запуска;
- что требуется для приемки.
Если подрядчик спокойно собирает эту информацию и приводит процесс в порядок, проект можно стабилизировать. Если же на любой запрос вы получаете раздражение, общие обещания и отсутствие конкретики, риск повышается.
Полезно отдельно проверить технические вещи: доступы, CMS, формы, структуру страниц, аналитику, адаптив, базовые SEO-поля. Если проект уже близок к запуску, лучше обнаружить проблемы до публикации, чем после того, как на сайт пойдет трафик.
Безопасный следующий шаг
Перед выбором подрядчика не нужно становиться техническим специалистом. Достаточно проверить управляемость: как человек задает вопросы, фиксирует объем, объясняет решения, учитывает заявки и аналитику, готовит сайт к поддержке и передаче.
Самая безопасная позиция для бизнеса — не искать исполнителя, который «сразу все обещает», а выбирать того, кто умеет уточнять, предупреждать об ограничениях и делать процесс прозрачным. Такой подход не гарантирует идеальный результат, но снижает вероятность получить сайт, который после запуска придется срочно переделывать.
Если вы сомневаетесь в текущем сайте, подрядчике или составе будущего проекта, разумно начать с короткой диагностики: что уже понятно, где есть риски, какие решения нужно зафиксировать до разработки и что проверить перед запуском. Для обсуждения задачи можно перейти в контакты.
