Плохие сайты редко начинаются с очевидно плохого разработчика. Чаще всё начинается с приятного разговора, красивого портфолио и предложения, в котором никто не определил, что именно означает «готово».
Этот гид — для владельца бизнеса, который выбирает фрилансера, студию или product team для корпоративного сайта, сервиса либо интернет-магазина. Он не поможет найти «самого талантливого» подрядчика за одну встречу. Зато даст процесс, в котором слабое предложение трудно замаскировать харизмой.
Короткий ответ: как выбрать разработчика сайта
Оценивайте не вкус и не количество технологий в презентации. Оценивайте пять вещей: поняла ли команда бизнес-задачу; какие приводит доказательства; насколько четко описывает scope и assumptions; как вы проверите результат; что останется в вашей собственности после завершения.
Evidence
Живые продукты, результаты, references и честный разговор о неудачах.
Scope
Deliverables, exclusions, assumptions, dependencies и change control.
Tests
Acceptance criteria, QA, security, accessibility и performance.
Ownership
Domain, accounts, repository, data, документация и право уйти.
До первого звонка напишите brief на одну страницу
Не начинайте с «нам нужен современный сайт». Напишите: кто пользователь; какое действие он должен выполнить; что бизнес хочет изменить; какие три flows критичны; какие системы нужно интегрировать; кто дает тексты, фото и product data; у дедлайна какая реальная причина; какой бюджетный диапазон вы готовы рассматривать.
Добавьте constraints: языки, рынки, privacy, payments, CRM, CMS, accessibility, migration и внутренние approvers. Хороший brief описывает проблему и границы, а не диктует 47 страниц и конкретный framework. Budget range позволяет отсечь решения другого масштаба: шаблон за две недели и custom platform на полгода нельзя сравнивать как один товар.
23 вопроса до подписания договора
Стратегия и доказательства
- Какую бизнес-проблему вы видите в нашем brief? Сильный ответ переформулирует задачу, а не повторяет ваши слова.
- Что вы сознательно не стали бы строить в первой версии? Опытная команда защищает фокус.
- Покажите два релевантных live-проекта. Какая часть была вашей? Работа с брендом не означает создание всего продукта.
- Что в похожем проекте пошло не по плану? Ищите конкретную ошибку, решение и изменение процесса.
- Можно поговорить с прошлым клиентом? Если нет — причина и альтернативные доказательства должны быть честными.
Scope, оценка и изменения
- Какие assumptions лежат в основе оценки? Готовые тексты, чистые данные, один approver, документированный API — это реальные зависимости.
- Что точно входит и не входит в цену? Уточните copy, SEO migration, analytics, integrations, browser QA, обучение, licenses и launch support.
- Кто готовит и загружает контент? Пустая страница технически готова, но к запуску — нет.
- Что сильнее всего может изменить бюджет или срок? Зрелая команда называет uncertainty заранее.
- Как согласуются изменения? Нужны описание, влияние на бюджет и сроки, письменное approval.
Команда и процесс
- Кто фактически будет делать работу? Попросите имена и роли delivery team, не только участников pitch.
- Какова их доступность и что будет при замене? Senior oversight раз в месяц — не senior delivery.
- Как часто мы увидим working software? Demo каждые 1–2 недели безопаснее большого reveal в конце.
- Какие решения и материалы нужны от нас? В timeline должны быть client dependencies, approver и сроки feedback.
Технология и качество
- Какую platform или architecture вы рекомендуете и почему? Ответ должен объяснять maintenance, редакторов, integrations и cost, а не моду.
- Как устроены staging, version control, review, testing и deployment? Версию нужно увидеть до production и уметь откатить.
- Какие security requirements вы проверяете? Для web app попросите checklist уровня риска: OWASP ASVS, secrets, dependencies, backups и incident process.
- Какой уровень accessibility и browser/device matrix входит? Нужны WCAG criteria, keyboard и screen-reader checks, а не слово «доступный».
- Какие performance targets фиксируем? Согласуйте страницы, условия измерения и Core Web Vitals либо иные бюджеты.
Владение, запуск и поддержка
- На кого оформляются domain, hosting/cloud, repository, analytics и third-party accounts? На вашу организацию, подрядчику выдается доступ.
- Кому принадлежат code, design, content и data, а что лицензируется? Нужен список themes, fonts, plugins и stock assets.
- Что означает acceptance и как проходит launch? Нужны observable criteria, UAT, ответственные, backup и rollback.
- Что происходит после launch или termination? Warranty, support, SLA, maintenance price, export, документация, credentials и knowledge transfer.
Scorecard для сравнения на 100 баллов
| Критерий | Вес | Что дает высокий балл |
|---|---|---|
| Понимание проблемы | 20 | Diagnosis, user flows, priorities и уместные возражения |
| Релевантные доказательства | 15 | Live work, точная роль, outcomes, reference, lessons |
| Scope и assumptions | 15 | Deliverables, exclusions, dependencies, change process |
| Quality и technology | 15 | Rationale, QA, security, accessibility, performance |
| Команда и процесс | 10 | Named team, cadence, demos, continuity |
| Ownership и handoff | 15 | Ваши accounts, ясный IP, docs, export и exit |
| Цена и риск | 10 | Comparable scope, milestones, прозрачная uncertainty |
Пусть каждый reviewer поставит баллы независимо, затем обсудите самые большие расхождения. Не давайте низкой цене автоматическую победу: proposal без content, licenses и migration способен оказаться самым дорогим.
Пять вопросов прошлому клиенту
- Что вы планировали получить и что реально запустили?
- Насколько фактические сроки и бюджет отличались от начальных — и почему?
- Работала ли та же команда, которую вам представили?
- Какой был самый неприятный сюрприз и как подрядчик отреагировал?
- Наняли бы вы их снова для такого же проекта?
Самостоятельно посмотрите live site на mobile, проверьте forms, checkout, keyboard navigation и broken states. Учитывайте, что продукт могли существенно изменить после передачи.
Что должно быть в нормальном предложении
Нужны diagnosis, outcomes, scope, exclusions, approach, named team, timeline с client dependencies, milestones, acceptance, price, payment schedule, change process, assumptions, ownership, warranty и ongoing costs.
Paid discovery честна, когда integrations или product logic еще не исследованы. Вы должны получить usable artifacts: validated scope, flows, architecture decisions, risks, backlog и точную оценку. Не требуйте от каждого финалиста бесплатно спроектировать продукт целиком.
Опасная схема — «50% сейчас, 50% когда готово», если готовность не определена. Лучше платить за demonstrable outcomes: согласованный scope, tested prototype, working staging increment, content-ready release и accepted launch.
Что зафиксировать в договоре
- deliverables, exclusions, assumptions и приоритет документов;
- milestones, client dependencies, review windows и acceptance criteria;
- fees, taxes, expenses, payment timing и pause;
- change control и полномочия одобрять расходы;
- IP, background IP, open-source и third-party licenses;
- confidentiality, personal data, subprocessors, security, incidents;
- warranties, defects, SLA и limitation of liability;
- termination, partial work, repository, export, credentials и transition.
Проверяйте договор с юристом своей юрисдикции. Acceptance должен быть наблюдаемым: не «форма готова», а «форма создает lead с нужными полями в CRM, не дублируется при повторном click и проходит agreed browser matrix».
Сайт должен оставаться вашим
Создайте на email организации accounts регистратора, DNS, cloud/hosting, Git repository, CMS, analytics, tag manager, Search Console, payment, email и consent tools. Vendor получает роль, необходимую для работы. Google рекомендует регулярно проверять permissions и удалять доступ и verification tokens бывших участников.
| Актив | До старта | При передаче |
|---|---|---|
| Domain / DNS | Организация — registrant и owner | 2FA, billing и recovery проверены |
| Code / design | Repo в вашей org; IP terms согласованы | Source, history, design files, licenses, build instructions |
| Infrastructure | Ваш cloud или ясный transfer plan | Environments, backups, secrets rotation, rollback |
| Data / analytics | Ваши properties и ownership | Exports, retention, permissions, tracking map |
| Operations | Внутренний owner назначен | Runbook, monitoring, vendor list, maintenance calendar |
Если переезд возможен только с разрешения подрядчика, это dependency. Exit plan нужен до первого deploy; для миграции Google также рекомендует заранее тестировать redirects, сохранять Search Console ownership и мониторить старые и новые URL.
Десять красных флагов
- Нет доступа к repository или production accounts.
- Domain и hosting оформлены на vendor без плана передачи.
- 100% оплаты до проверяемого deliverable.
- Fixed price без assumptions и exclusions для неизвестной задачи.
- «SEO включено» без перечня работ и migration plan.
- Proprietary CMS без documented export.
- Нет staging, backups, version control или rollback.
- На pitch — seniors, в delivery proposal команда не названа.
- Десятки features, но ни одного non-goal.
- Только screenshots без live work, outcomes и references.
Отбор за 10 рабочих дней
Пригласите 3–5 кандидатов. Дайте всем одинаковый brief и общие письменные ответы. На финальном call говорите с delivery lead. Затем независимо заполните scorecard, проверьте reference, выровняйте scope двух финалистов и лишь тогда сравните price.
Частые вопросы
Фрилансер или веб-студия?
Фрилансер часто быстрее и дешевле для четкой небольшой задачи. Студия полезнее, когда одновременно нужны strategy, design, development, QA и continuity. Смотрите на реальную команду, а не форму бизнеса.
Сколько предложений получить?
Обычно достаточно трех–пяти. Большее количество создает шум, если brief еще не позволяет сравнить одинаковый scope.
Сколько платить заранее?
Универсального процента нет. Deposit за резерв команды нормален, но дальнейшие платежи лучше привязать к milestones и acceptance.
Кому должны принадлежать сайт, код и домен?
Domain, business accounts, data и repository должна контролировать ваша организация. Custom IP и third-party licenses следует прямо определить в договоре.
Как проверить разработчика?
Изучите live work и точный вклад, поговорите с delivery team и клиентом, попросите рассказать о провале и оцените proposal по scorecard.
Источники и дата проверки
Материал проверен 16 августа 2026 года по OWASP ASVS, WCAG 2.2, вопросам supplier assurance от NCSC, рекомендациям Google по Search Console permissions и site migrations. Это procurement guide, не юридическая консультация.
Читайте дальше: как запустить интернет-магазин, как выбрать ecommerce platform и как оценить custom AI development.