Как выбрать подрядчика на разработку сайта и не попасть в vendor lock-in
Большинство проблем с сайтом начинаются не после релиза, а до первого платежа. Бизнес выбирает подрядчика по картинкам, обещаниям и приятному созвону, а потом получает срыв сроков, размытый объем работ и полную зависимость от человека, который держит код, домен и хостинг у себя.
Короткий вывод: выбирать подрядчика нужно не по дизайну в портфолио, а по шести вещам: понимает ли он цели бизнеса, умеет ли считать смету прозрачно, закрепляет ли ownership, показывает ли процесс тестирования, называет ли реальную команду и готов ли работать по понятным контрольным точкам.
Главный риск не в том, что подрядчик сделает “некрасиво”. Главный риск в том, что вы не сможете управлять проектом, проверить результат и забрать актив себе без доплат и конфликтов.
Ниже — полный buyer-guide для собственника: как проверить подрядчика, какие вопросы задать на созвоне, какие документы запросить до договора и по каким признакам понять, что проект почти наверняка уйдет в перерасход.
Что смотреть первым делом: не визуал, а результат
Красивый портфолио-слайд не говорит почти ни о чем. Проверять нужно живые проекты: как они открываются на мобильном, быстро ли грузятся ключевые страницы, понятна ли структура, есть ли реальный CTA, формы, кейсы, юридические страницы и базовая SEO-архитектура. Если подрядчик показывает только макеты без работающих ссылок, это не кейсы, а презентация.
Следующий уровень — релевантность. Подрядчик не обязан иметь десять проектов именно в вашей нише, но он должен показать, что понимает похожую механику продаж: как работает многостраничный B2B-сайт, как устроен каталог, как собираются лиды, как выстраивается доверие на экспертном сайте, как проект готовится к SEO и приемке.
Полезный вопрос на первом звонке звучит просто: «Как вы поймете, что релиз был успешным?» Если в ответе есть заявки, качество лидов, скорость, индексация, корректная передача доступов и приемка, это хороший сигнал. Если ответ упирается только в “сдадим вовремя” или “сделаем современный дизайн”, вы слышите про процесс подрядчика, а не про результат бизнеса.
Шесть критериев, по которым стоит сравнивать подрядчиков
1. Подрядчик задает вопросы про бизнес, а не только про внешний вид
Сильный подрядчик сначала разбирает продукт, каналы трафика, воронку, ограничения и цели. Он уточняет, какой трафик планируется, что должно считаться конверсией, кто готовит контент, какие интеграции критичны, какие страницы нужны на старте и как будет проходить приемка. Слабый подрядчик перескакивает сразу к дизайну, потому что дизайн проще продавать, чем ответственность за результат.
2. В смете видно этапы, а не только итоговую сумму
Если в предложении написано “сайт под ключ — 150 000 ₽” без расшифровки, это не прозрачная смета. Нормальный документ разделяет работу на этапы: аналитика, прототип, дизайн, разработка, интеграции, тестирование, релиз. У каждого этапа есть результат, срок и критерий завершения. Именно так потом управляют бюджетом, а не через созвоны в стиле “это не входило”.
3. Ownership закреплен до старта
Один из самых дорогих сценариев для бизнеса — сайт вроде бы оплачен, но репозиторий не передан, домен оформлен не на вас, доступы к хостингу держит подрядчик, а любые правки идут только через него. Это и есть vendor lock-in. Если ownership не закреплен в договоре и процессе передачи, риск проекта резко растет, даже если команда выглядит сильной.
4. Есть понятный QA и сценарий приемки
Спросите, как подрядчик проверяет формы, мобильную версию, передачу лидов, индексацию и критические пользовательские сценарии. Ответ “мы все тестируем” не считается. Нужны конкретные шаги: кто тестирует, по какому чеклисту, что фиксируется в акте приемки и как исправляются критические баги после релиза.
5. Понятно, кто именно делает проект
Если на созвоне один человек, а потом выясняется, что код отдается неизвестному исполнителю без вашего участия и контроля, это управленческий риск. Вам не обязательно видеть всю внутреннюю структуру команды, но вы должны понимать, кто отвечает за проект, кто пишет код, кто согласует релиз и кто будет на связи в критический момент.
6. Есть ритм отчетности и точки контроля
Проект без промежуточных точек почти всегда идет в зону сюрпризов. Хороший подрядчик заранее говорит, когда будет прототип, когда покажет дизайн, когда даст демо-доступ, когда пройдет тестирование и что именно вы проверяете на каждом этапе. Это снижает риск внезапных доработок в конце и удерживает ожидания обеих сторон в реальности.
Какие документы запросить до договора
- Смета по этапам: результат этапа, срок, стоимость, критерий приемки.
- Черновик ТЗ или discovery-summary: чтобы убедиться, что подрядчик правильно понял объем.
- Порядок передачи доступов: домен, хостинг, аналитика, CRM, репозиторий.
- Регламент пострелизной поддержки: кто и как чинит критические баги после запуска.
- Перечень зависимостей: кто отвечает за контент, интеграции, approvals и внешние сервисы.
Этот пакет полезен сразу по двум причинам. Во-первых, он помогает сравнивать предложения по одинаковым критериям. Во-вторых, он показывает зрелость подрядчика ещё до подписания договора. Если человек не может структурировать проект на бумаге, на практике хаоса обычно будет только больше.
7 красных флагов, после которых лучше поставить паузу
- Не задает вопросы про цели бизнеса и воронку.
- Обещает быстрые SEO-результаты без оговорок и ограничений.
- Не показывает живые проекты или дает только скриншоты.
- Избегает темы ownership, репозитория и хостинга.
- Не может объяснить, как проходит тестирование и приемка.
- Просит крупную предоплату без демо, этапов и критериев.
- Называет общую сумму, но не может разложить ее на этапы и ответственность.
Один флаг еще не всегда катастрофа. Но если их три и больше, вы уже не выбираете подрядчика, а берете на себя риск менеджмента за него.
Как провести созвон так, чтобы он реально что-то показал
Лучший способ быстро понять уровень подрядчика — не просить “рассказать о себе”, а пройтись по рабочим вопросам. Например: какие страницы вы бы предложили на старте, как вы считаете успех релиза, что входит в ownership, как проверяете мобильную версию, кто отвечает за интеграции, как выглядит акт приемки, какие риски видите в нашей задаче. Сильный подрядчик не будет на все отвечать “зависит”. Он разложит варианты, ограничения и trade-offs.
Особенно внимательно слушайте, как человек говорит о рисках. Профессионал почти всегда называет их сам: сроки контента, ограничения по интеграциям, влияние архитектуры на SEO, зависимость от доступов, порядок приемки. Непрофессионал чаще продает ощущение простоты и бесконечной предсказуемости.
Что проверить в договоре до оплаты
В договоре должны быть закреплены этапы, сроки, критерии приемки, состав работ, ownership кода и доступов, формат правок, порядок исправления критических багов и условия расторжения. Если этого нет, спор почти неизбежно переедет в стадию “мы по-разному поняли задачу”.
Отдельно проверьте три вещи: кому принадлежат дизайн и код после оплаты, на чьих аккаунтах размещаются домен и хостинг, и что считается завершением проекта. Именно вокруг этих пунктов чаще всего и возникают конфликты после релиза.
FAQ
Сколько подрядчиков реально стоит сравнить?
Обычно достаточно трех. Этого хватает, чтобы увидеть рынок, не утонуть в созвонах и понять, кто умеет считать проект по делу.
Нужен ли технический аудит до подписания?
Да, если проект включает интеграции, каталог, мультиязычность или ощутимый бюджет. Чем сложнее сценарии, тем дороже обходится ошибка на входе.
Можно ли подписывать договор без ТЗ?
Нежелательно. Минимум нужен discovery-этап или письменная фиксация объема, иначе смета и ожидания почти наверняка начнут расползаться.
Какой главный признак зрелого подрядчика?
Он не прячет структуру проекта. Наоборот: спокойно показывает этапы, ограничения, ownership, порядок тестирования и критерии приемки.
Внутренние ссылки
Цены и этапы оплаты · Портфолио и кейсы · Как подготовить ТЗ · Чеклист приемки сайта
Schema и источники
Для материала подходит связка Article + FAQPage + HowTo. Для технической проверки кейсов и критериев релиза полезны Google Search Central и web.dev.
Нужна независимая проверка подрядчика, сметы или договора перед оплатой? Отправить проект на аудит.
