Как выбрать подрядчика на разработку сайта: 12 вопросов до договора

Почему выбор по цене коммерческого предложения не работает

Два предложения с одинаковым названием «разработка сайта» могут включать разный продукт. В одном есть исследование, тексты, адаптивные состояния, CMS, аналитика, QA и запуск; в другом — только дизайн нескольких экранов и вёрстка. Низкая итоговая сумма не доказывает эффективность, пока вы не сравнили границы, допущения и то, что остаётся на стороне заказчика.

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

Кого выбирать: фрилансера, студию или продуктовую команду

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

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

12 вопросов, которые стоит задать до договора

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

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

Как проверять портфолио, а не презентацию портфолио

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

Ищите не только сходство отрасли, но и сходство сложности. Для маркетплейса важны каталог и роли, для бренда — система носителей, для рекламного продукта — производство визуального контента. В портфолио DUO MESH можно отдельно посмотреть ART KEY как цифровую платформу, «Дикую тишь» как связку бренда, упаковки и сайта и «Бренд в движении» как motion-систему. Эти работы полезны для проверки разных компетенций, а не как обещание одинакового результата для любой компании.

Как привести разные сметы к общему знаменателю

Перенесите предложения в одну таблицу по результатам этапов. Вместо строки «UX/UI — 300 часов» уточните, какие пользовательские пути, состояния и размеры экрана будут спроектированы. Вместо «разработка» — какие шаблоны, интеграции, роли, CMS-функции, тесты и среда публикации входят. Отдельно вынесите лицензии, хостинг, платные сервисы, налоги и поддержку.

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

Безопасность нужно проверять до разработки

Безопасность нельзя оставить строкой «по стандартам». NIST SSDF рекомендует включать практики защищённой разработки в жизненный цикл и использовать общий язык между заказчиком и поставщиком. OWASP ASVS прямо предлагает проверяемые требования для веб-приложений и отмечает их применимость при закупке и в договорах.

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

Что закрепить в договоре и приложениях

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

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

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

Красные флаги до старта

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

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

Как провести безопасный платный пилот

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

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