Нанять веб-разработчика и получить работающий сайт в срок — задача решаемая, если знать правильную последовательность шагов. Большинство проблем с фрилансерами-разработчиками возникает не из-за низкой квалификации специалиста, а из-за пропущенных этапов: нет ТЗ, нет договора, нет промежуточных демо, нет чёткой процедуры приёмки. Этот гайд закрывает весь процесс — от брифа до передачи доступов.
Это опорная статья кластера C3 «Управление фриланс-проектом». Здесь разобраны все этапы A→Z. Смежные темы: ТЗ на разработку сайта, договор с фрилансером, чек-лист ведения проекта.
Что вы узнаете из статьи
- Как составить ТЗ, с которым разработчик не уйдёт в сторону
- Как собрать шортлист и провести пресейл-звонок
- Какие документы нужны до старта
- Как выстроить этапы оплаты через эскроу
- Как проводить промежуточные демо и финальную приёмку
- Что входит в передачу доступов и документации
Этап 1. Техническое задание: основа без которой нельзя стартовать
ТЗ — единственный инструмент, который переводит вашу идею в конкретную задачу для разработчика. Без него вы получите то, что разработчик придумал сам, — и переделки войдут в стандартную программу.
Минимальное ТЗ на сайт включает 7 блоков:
- Цель и задача сайта — что именно должен делать сайт (продавать, информировать, генерировать лиды, обрабатывать заказы). Конкретно: «лендинг собирает заявки через форму и передаёт их в CRM».
- Целевая аудитория — кто придёт на сайт, что ищет, с каких устройств (мобильный/десктоп).
- Структура и страницы — список всех страниц с кратким описанием содержимого каждой.
- Функциональные требования — что должен уметь сайт: форма обратной связи, личный кабинет, каталог, корзина, интеграция с CRM/платёжной системой.
- Технический стек — если у вас есть предпочтения (React, Vue, WordPress, Tilda) или ограничения (хостинг без поддержки Node.js). Если не знаете — оставьте на усмотрение разработчика с обоснованием выбора.
- Референсы — 3–5 сайтов, которые нравятся. Не «скопируй», а «вот уровень детализации и стиль».
- Критерии приёмки — по каким признакам вы поймёте, что сайт готов: производительность (Lighthouse Score > 80), адаптивность (мобильный + планшет), работающие формы, прошедшие кросс-браузерное тестирование.
Полный шаблон с примерами — в статье ТЗ на разработку сайта: шаблон с примерами. Там разобраны кейсы для лендинга, корпоративного сайта и интернет-магазина.
💡 Один из способов ускорить написание ТЗ — попросить разработчика провести платную пресейл-сессию (1–2 часа, 3 000–8 000 ₽). Опытный специалист задаст правильные вопросы и поможет сформулировать требования.
Что должно быть в ТЗ для разных типов сайтов
Объём и детализация ТЗ зависят от сложности проекта:
Лендинг. Достаточно 1–2 страниц: цель страницы, структура секций, форма сбора заявок (поля, куда уходят данные), 3–5 референсов, мобильная адаптация — обязательна. Укажите конкретный результат: «конверсия в заявку не ниже 3% по данным Метрики».
Корпоративный сайт. 3–7 страниц ТЗ: список всех страниц, структура навигации, требования к CMS (кто и как будет обновлять контент), интеграции (почта, CRM, аналитика). Для каждой страницы — перечень обязательных блоков.
Интернет-магазин. Самое объёмное ТЗ: каталог с фильтрами (сколько категорий, атрибуты товаров), корзина и checkout, платёжные системы (ЮKassa, Сбер, СБП), личный кабинет покупателя, интеграция со складом/1С, уведомления. Не забудьте: SEO-требования к URL-структуре и метатегам.
Сервис с личным кабинетом. Обязательно: ролевая модель (кто что видит и делает), сценарии использования для каждой роли, требования к безопасности данных, API-интеграции с внешними системами, нагрузочные требования (сколько пользователей одновременно).
Этап 2. Шортлист и пресейл-звонок: как выбрать из множества кандидатов
После публикации заявки на Gde.Expert вы получите отклики в течение 30–60 минут. Задача — не выбрать самого дешёвого и не самого красноречивого, а найти того, чей опыт совпадает с вашей задачей.
Формирование шортлиста (3–5 кандидатов). Отсекайте сразу тех, кто:
- Прислал шаблонный отклик без упоминания вашей задачи
- Не может показать ни одного релевантного проекта
- Даёт цену без каких-либо уточняющих вопросов (слишком низкая цена без вопросов = не читал ТЗ)
- Предлагает сроки, которые явно нереальны (лендинг за 1 день — красный флаг)
Пресейл-звонок (30–45 минут). Проводите с каждым из шортлиста. Вопросы:
- «Покажите 2–3 проекта, похожих по типу и сложности на мой». Если нет — узнайте почему.
- «Как вы поняли мою задачу? Что бы уточнили в ТЗ?» — хороший разработчик задаст встречные вопросы, а не скажет «всё понял».
- «Из каких этапов состоит ваш процесс работы?» — должен назвать конкретные этапы с промежуточными результатами.
- «Как вы работаете с правками? Что считаете правкой, а что переработкой?» — критично для предотвращения конфликтов.
- «Какой стек будете использовать и почему именно он для этой задачи?» — проверяет компетенцию.
- «Как будет проходить коммуникация: как часто, в каком формате?»
Типичные сроки разработки в 2026:
| Тип сайта | Минимум | Реалистично | Сложный кейс |
|---|---|---|---|
| Лендинг (конструктор) | 3–5 дней | 1–2 недели | 3 недели |
| Кастомный лендинг | 1 неделя | 2–3 недели | 4 недели |
| Корпоративный сайт (5–15 страниц) | 3 недели | 4–8 недель | 10 недель |
| Интернет-магазин на CMS | 4 недели | 6–10 недель | 14 недель |
| Сложный e-commerce с интеграциями | 8 недель | 12–16 недель | 20+ недель |
| Мобильное приложение (MVP) | 8 недель | 12–20 недель | 24+ недели |
💡 Главная причина срыва сроков — поздний контент со стороны заказчика. Тексты, фото, логотип, данные для интеграций — всё это должно быть готово до старта разработки или по согласованному с разработчиком графику.
Этап 3. Договор и схема оплаты: как не потерять деньги
Для проектов от 30 000 ₽ договор обязателен. Он фиксирует задачу, сроки, ответственность за задержки и права на результат.
Восемь ключевых пунктов договора подробно разобраны в статье Договор с фрилансером: 8 пунктов, без которых нельзя. Здесь сосредоточимся на схеме оплаты.
Рекомендуемая схема оплаты через эскроу:
Этапная оплата снижает риск для обеих сторон: разработчик уверен, что получит деньги за выполненную работу, заказчик — что деньги заморожены и не уйдут без результата.
| Этап | Оплата от суммы | Что сдаёт разработчик |
|---|---|---|
| Старт (аванс) | 30% | Подписанный договор, план работ с датами |
| Дизайн-макет утверждён | 20% | Figma-файл всех страниц, адаптивные версии |
| Вёрстка и фронтенд готовы | 20% | Работающий сайт на тест-сервере |
| Функциональность внедрена | 20% | Работающие интеграции, формы, CMS |
| Финальная приёмка | 10% | Передача всех доступов, документации, исходников |
Эскроу Gde.Expert работает по этому принципу: вы пополняете баланс на сумму сделки, деньги замораживаются. Каждый этап разблокируется вашим подтверждением. Разработчик видит, что деньги есть — и работает спокойно. Вы видите, что деньги не ушли раньше времени.
Этап 4. Кикофф и ведение проекта: как не потерять контроль
Кикофф-встреча (1–2 часа в начале проекта) — обязательна для проектов дольше 2 недель. Повестка:
- Подтверждение ТЗ: все ли требования поняты правильно?
- Согласование стека технологий и инструментов
- План работ с датами промежуточных демо
- Каналы коммуникации (мессенджер, трекер задач)
- Процедура согласования изменений
Промежуточные демо. Для проектов дольше 3 недель договоритесь о еженедельных демо (30–60 минут). Разработчик показывает текущее состояние на тест-сервере — вы даёте обратную связь. Это предотвращает ситуацию, когда за 2 месяца сделали «не то».
💡 Используйте готовый чек-лист ведения проекта с фрилансером — там 23 пункта от кикоффа до финальной приёмки, разбитых по этапам с указанием времени на каждый.
Трекинг задач. Для проектов от 4 недель попросите разработчика вести задачи в общем трекере: Notion, Trello, Linear, GitHub Projects. Это даёт прозрачность: вы видите, что сделано, что в работе, что заблокировано.
Этап 5. Код-ревью и финальная приёмка
Финальная приёмка — момент, когда вы подтверждаете, что работа выполнена согласно ТЗ. Чтобы это не превращалось в «ну вроде норм», используйте чек-лист приёмки.
Функциональная проверка:
- Все страницы по ТЗ присутствуют и работают
- Все формы отправляют данные (проверьте каждую)
- Интеграции работают: CRM получает данные, платёжная система проводит тестовый платёж
- Личный кабинет (если есть): регистрация, вход, смена пароля
- Поиск и фильтры работают (для каталогов и магазинов)
Технический чек-лист:
- Lighthouse Score: Performance ≥ 80, Accessibility ≥ 80, SEO ≥ 90
- Адаптивность: тест на мобильном (iOS/Android), планшете, десктопе
- Кросс-браузерность: Chrome, Firefox, Safari, Edge
- SSL-сертификат установлен, сайт открывается по HTTPS
- Нет битых ссылок (проверьте инструментом вроде Broken Link Checker)
- Страница 404 кастомная и ведёт на главную
Код-ревью для серьёзных проектов. Для проектов от 150 000 ₽ рекомендуем независимое код-ревью: привлечь другого разработчика на несколько часов для проверки структуры кода, безопасности, читаемости и наличия уязвимостей. Стоимость: 5 000–15 000 ₽, экономия на последующих переделках — в разы больше.
Промежуточный CTA
Ищете веб-разработчика для своего проекта? На Gde.Expert верифицированные специалисты с подтверждённым ИНН откликаются в среднем за 27 минут. Оплата через эскроу, договор защищён платформой.
Опубликовать заявку на разработку сайта →
Этап 6. Передача доступов, документации и прав
Финальная оплата должна быть обусловлена полной передачей всего пакета. Не «получу потом» — передача до последнего платежа.
Что должно быть передано:
- Хостинг и домен: логин/пароль панели управления хостингом, доступ к регистратору домена (или перевод домена на ваш аккаунт).
- CMS/панель администратора: аккаунт администратора, инструкция по управлению контентом.
- Репозиторий или исходный код: GitHub/GitLab репозиторий с историей коммитов или архив с полным кодом.
- Документация: README с инструкцией по развёртыванию, описание структуры БД (если есть), список используемых библиотек и версий.
- Сторонние сервисы: доступы к подключённым API (Яндекс.Метрика, CRM, рассылка, платёжная система).
- Гарантийные обязательства: зафиксируйте в договоре: разработчик устраняет баги, обнаруженные в течение 30–90 дней после запуска, бесплатно.
Права на код. Убедитесь, что в договоре прямо указано: все права на разработанный код, дизайн и контент переходят заказчику после финальной оплаты. Разработчик сохраняет право показывать проект в портфолио (если не оговорено обратное).
Как выбрать технический стек: советы для нетехнического заказчика
Один из самых частых вопросов на пресейле: «А на чём лучше сделать мой сайт?». Нетехническому заказчику сложно оценить ответ разработчика. Вот ориентиры.
Лендинг или простой сайт-визитка. Оптимальный выбор — конструктор (Tilda, Readymag, Wix) или WordPress с готовым шаблоном. Дешевле, быстрее, не требует разработчика для обновления контента. Если разработчик предлагает React или Vue.js для лендинга без сложной интерактивности — скорее всего, это оверинжиниринг.
Корпоративный сайт с регулярным обновлением контента. WordPress или другая CMS (1C-Битрикс для крупных компаний с 1С). Ваша команда сможет обновлять контент без разработчика. Кастомная разработка оправдана, если есть нестандартные требования к функциональности.
Интернет-магазин. До 1 000 SKU и без сложных интеграций — Tilda, WooCommerce, OpenCart. Средний масштаб — Bitrix, PrestaShop. Крупный e-commerce с кастомной логикой — индивидуальная разработка на Laravel, Django или Node.js.
Веб-приложение или SaaS. Здесь однозначного ответа нет — стек определяется нагрузкой, командой поддержки, требованиями к безопасности. Для MVP — стандартные решения (Laravel + Vue, Django + React). Для масштабирования — микросервисы.
Главный вопрос, который стоит задать разработчику: «Кто будет поддерживать этот стек после вас? Насколько легко найти разработчика, если мне понадобится помощь через год?» Экзотический стек может превратиться в проблему при смене исполнителя.
Как не попасть на Scope Creep: управление изменениями
Scope Creep — постепенное расширение объёма работ без пересмотра бюджета и сроков. Одна из главных причин конфликтов между заказчиком и разработчиком.
Типичный сценарий: заказчик в процессе работы добавляет «маленькие» пожелания — ещё одну страницу, другую цветовую схему, интеграцию с новым сервисом. По отдельности каждое кажется мелочью, в сумме — это дополнительные 30–50% работы без оплаты.
Как предотвратить:
Зафиксируйте в договоре процедуру изменений: любое новое требование, не входящее в ТЗ, оформляется как дополнительное соглашение с указанием стоимости и влияния на сроки. Устные договорённости не имеют юридической силы.
Перед утверждением любого изменения задайте себе три вопроса: это действительно нужно для запуска? Это было в ТЗ? Готовы ли вы заплатить за это дополнительно? Если ответ «нет» хотя бы на один — откладывайте на вторую итерацию.
Введите понятие «версия 2.0»: всё, что появилось в процессе разработки, но не было в исходном ТЗ — это следующая версия. Запускайте текущую, собирайте данные, улучшайте осознанно.
Как разработчик должен реагировать на запрос изменений:
Хороший разработчик не говорит «окей, сделаю» на каждый запрос. Он оценивает: сколько времени займёт, как это влияет на текущий план, нужно ли пересматривать договор. Если разработчик соглашается на всё без оценки — либо он занижает реальный объём, либо потом выставит счёт сюрпризом.
Типичные проблемы и как их предотвратить
| Проблема | Причина | Решение |
|---|---|---|
| Разработчик пропал после аванса | Оплата без эскроу | Использовать эскроу, не переводить деньги напрямую |
| Сайт не соответствует ТЗ | ТЗ было расплывчатым | Чёткие критерии приёмки в ТЗ |
| Срыв сроков | Нет промежуточных демо | Еженедельные демо, даты в договоре |
| «Бесконечные» правки | Нет ограничения на правки в договоре | Зафиксировать 2–3 раунда правок |
| Разработчик не передаёт доступы | Нет условия в договоре | Привязать финальный платёж к передаче |
| Конфликт по цене за дополнения | Scope Creep | Фиксировать любые изменения письменно |
Как выстроить долгосрочные отношения с разработчиком
Если проект прошёл успешно, не упустите возможность выстроить долгосрочное сотрудничество. Хороший разработчик, знающий вашу кодовую базу, продукт и процессы, стоит дороже, чем поиск нового специалиста каждый раз.
После успешного проекта:
Оставьте развёрнутый отзыв на платформе — это мотивирует разработчика и помогает другим заказчикам. Сохраните контакт разработчика и договоритесь о приоритете при следующей задаче. Если планируете регулярную поддержку — обсудите формат: почасовой ретейнер (5–10 часов в месяц на баг-фиксы и мелкие доработки) дешевле и удобнее, чем каждый раз искать нового исполнителя.
Когда стоит менять разработчика:
Смена исполнителя оправдана, если проект был провальным: сроки сорваны, качество не принято, коммуникация была некомфортной. Но если проект прошёл хорошо и у разработчика есть доступ к вашему коду — смена ради экономии 10–15% обычно не окупается: новый специалист потратит время на изучение существующего кода, что выражается в деньгах.
Передача проекта новому разработчику:
Если смена всё же нужна — убедитесь, что прежний разработчик передал: полный исходный код с комментариями, документацию по архитектуре и нестандартным решениям, список всех интеграций с описанием конфигурации, доступы ко всем сервисам. Без этого новый разработчик потратит 30–50% времени на «раскопки» вместо работы.
Стоимость поддержки после запуска
Многие заказчики забывают учесть этот пункт в бюджете. Сайт — не разовый продукт, это живая система.
Что входит в типичную поддержку:
- Обновление CMS, плагинов, зависимостей (критично для безопасности)
- Мониторинг доступности и производительности
- Резервное копирование
- Исправление багов, выявленных после запуска
- Мелкие доработки: новые страницы, правки контента, изменения форм
Типичные форматы и стоимость:
Гарантийный период (30–90 дней) — исправление багов бесплатно, входит в договор. Почасовой ретейнер — 5–15 часов в месяц по договорённой ставке (1 500–4 000 ₽/час). Фиксированная ежемесячная плата за базовую поддержку — 5 000–25 000 ₽ в зависимости от объёма.
Заложите поддержку в бюджет ещё на этапе планирования: 10–15% от стоимости разработки в год — разумный ориентир для несложных сайтов.
Часто задаваемые вопросы
Сколько стоит разработка сайта у фрилансера в 2026? Лендинг: 25 000–80 000 ₽ (2–4 недели). Корпоративный сайт: 80 000–250 000 ₽ (4–8 недель). Интернет-магазин на CMS: 80 000–250 000 ₽ (6–12 недель). Сложный e-commerce с интеграциями: от 300 000 ₽ (12–20 недель).
Как проверить качество кода до финальной оплаты? Попросите доступ к репозиторию на GitHub/GitLab и проводите промежуточные демо на тест-сервере. Для серьёзных проектов привлеките независимого разработчика на код-ревью (5 000–15 000 ₽). Используйте Lighthouse для проверки производительности.
Нужен ли договор при работе с фрилансером-разработчиком? Да, для проектов от 30 000 ₽ — обязательно. Договор фиксирует ТЗ, сроки, стоимость, порядок правок, права на код. Подробнее — в статье Договор с фрилансером: 8 пунктов.
Сколько занимает разработка лендинга? Простой лендинг на конструкторе — 3–7 дней. Кастомный с анимацией — 10–21 день. Нестандартный дизайн с адаптивом — 2–4 недели. Часто задержки возникают из-за позднего предоставления контента со стороны заказчика.
Как передаются права на разработанный сайт? После финальной оплаты заказчик получает: доступ к хостингу и домену, репозиторий с кодом или архив исходников, доступ к CMS, документацию по развёртыванию. Все права на код закрепите в договоре прямым указанием.
Как оценить компетентность разработчика без технических знаний
Один из самых частых вопросов от нетехнических заказчиков: «Как понять, что разработчик действительно хороший, если я не разбираюсь в коде?»
Смотрите на процесс, а не только на результат. Опытный разработчик задаёт уточняющие вопросы до начала работы, предлагает план с этапами, объясняет технические решения простым языком. Если разработчик говорит «сделаю всё» без единого вопроса — это тревожный сигнал.
Попросите рассказать о провальном проекте. Это неожиданный, но очень показательный вопрос. Честный и опытный специалист расскажет о реальной ситуации и объяснит, что извлёк из неё. Тот, кто говорит «у меня провалов не было» — либо мало работал, либо не рефлексирует.
Проверьте скорость и структуру ответов. На этапе переговоров обратите внимание: разработчик отвечает структурированно? Держит сроки даже в переписке? Уточняет непонятные моменты вместо того, чтобы угадывать? Коммуникационные паттерны в переговорах — точная проекция поведения в работе.
Запросите ссылку на живой проект. Лучше любого портфолио — работающий сайт, к которому разработчик имел отношение. Откройте его на мобильном, проверьте скорость загрузки через PageSpeed Insights, посмотрите на детали: нет ли битых ссылок, корректно ли работают формы. Это занимает 10 минут и даёт больше, чем час переговоров.
Небольшое тестовое задание. Для проектов от 150 000 ₽ оправдано платное тестовое: небольшая задача (4–8 часов) по рыночной ставке. Это покажет качество кода, подход к документированию и стиль коммуникации в рабочем режиме. Большинство сильных разработчиков соглашаются на оплачиваемое тестовое.
Заключение
Найм веб-разработчика — это управляемый процесс из шести чётких этапов: ТЗ → шортлист и пресейл → договор и эскроу → кикофф → промежуточные демо → приёмка и передача. Пропуск любого из них увеличивает риск переделок, задержек и споров.
Самые дорогостоящие ошибки: старт без ТЗ, аванс без эскроу, отсутствие промежуточных демо, финальный платёж до передачи всех доступов. Избегайте их — и вероятность успешного проекта с первого раза приближается к 90%.
Разместите заявку на Gde.Expert — верифицированные веб-разработчики с подтверждённым ИНН откликнутся в среднем за 27 минут. Оплата защищена эскроу, комиссия платформы 0–5%.