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

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

Портфолио: смотреть не на картинки, а на процесс

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

Техническое задание — не формальность, а страховка

Отсутствие подробного технического задания — один из главных источников конфликтов на проекте. Если задание сформулировано в одно предложение вроде «сделайте нам современный сайт», у заказчика и подрядчика неизбежно сложатся разные ожидания о том, что именно должно получиться. Хороший подрядчик сам предложит проработать ТЗ перед стартом, а не начнёт разработку по общим словам.

Договор: что должно быть прописано

• Точный список работ и их стоимость — не общая сумма проекта, а разбивка по этапам, чтобы было понятно, за что именно вы платите на каждом шаге.
• Сроки по этапам, а не только финальный дедлайн — промежуточные контрольные точки позволяют заметить срыв сроков заранее, а не в последний момент перед запуском.
• Условия передачи прав. Кому принадлежит код, дизайн и контент после оплаты — этот пункт особенно важен, если в будущем вы захотите сменить подрядчика на поддержке.
• Условия постпродакшн-поддержки. Что происходит после сдачи сайта: входит ли исправление багов в стоимость, на какой срок, и что считается багом, а что — новой доработкой.

Технологический стек: не гнаться за модой

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

Вопросы, которые стоит задать до старта

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

Красные флаги при выборе

• Стоимость значительно ниже рынка без внятного объяснения, за счёт чего достигается экономия
• Нежелание фиксировать объём работ и сроки в договоре, предложение работать «по доверию»
• Отказ показать контакты хотя бы одного прошлого клиента
• Требование полной предоплаты без разбивки на этапы

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

Фиксированная цена против почасовой оплаты

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

Как оценить техническую компетентность подрядчика без глубоких знаний в разработке

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

Промежуточная приёмка этапов

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

Что происходит после сдачи сайта

Запуск сайта — не конец отношений с подрядчиком, если только речь не о разовой простой задаче. Обновления контента, техническая поддержка, доработки по мере роста бизнеса — всё это стоит обсудить на этапе выбора подрядчика, а не после того, как первая необходимость в доработке уже возникла. Разные подрядчики по-разному относятся к поддержке уже сданных проектов, и это стоит уточнить заранее наравне с ценой самой разработки.