Финальный платёж - точка, после которой требовать исправлений и доступов становится намного сложнее. Приёмка сайта у разработчика - это проверка результата по конкретным пунктам, а не разговор на доверии и не подпись под актом ради формальности. За годы работы фрилансером и в связке со студиями я видел десятки ситуаций, когда клиент закрывал остаток оплаты, а через месяц выяснял, что домен зарегистрирован на аккаунт разработчика, исходники так и не переданы, а форма обратной связи отправляет заявки на чужую почту. Ниже - чек-лист, по которому я сдаю собственные проекты и который советую применять к любому подрядчику: фрилансеру, студии, агентству.
Доступы и инфраструктура: с этого начинается любая приёмка
Первый вопрос на приёмке - не «красиво ли получилось», а «кому что принадлежит». Домен, хостинг, аккаунты платёжных систем и CRM должны быть зарегистрированы на вас или переведены на ваш аккаунт до перевода последнего платежа. Разработчик, который предлагает «оставить пока на моём хостинге, потом перенесём» - стандартная схема удержания проекта на случай спора.
| Что проверять | Как проверить | Красный флаг |
|---|---|---|
| Домен | Whois-сервис показывает вас или вашу компанию как владельца | Владелец - email или ИП разработчика |
| Хостинг/сервер | Логин в панель управления (ISPmanager, Timeweb, VPS) под вашей учёткой | Доступ только «просмотр», без прав на биллинг |
| Админка CMS | Отдельный аккаунт администратора, не общий логин разработчика | Один логин на всех, включая старые проекты студии |
| Репозиторий | Git-репозиторий передан вам в организацию или доступ добавлен как owner | Код существует только на компьютере разработчика |
| Аналитика | Яндекс.Метрика и GA4 привязаны к вашему аккаунту | Счётчик зарегистрирован на почту студии |
| Платёжный шлюз | Личный кабинет эквайринга (T‑Bank, ЮKassa) оформлен на вашу компанию | Тестовые ключи так и остались в проде |
| SSL-сертификат | Сертификат выпущен и автопродление настроено на вашем аккаунте | Сертификат привязан к почте разработчика |
Если часть доступов физически нельзя передать (например, тариф хостинга привязан к юрлицу студии) - фиксируйте это в акте отдельным пунктом с датой переноса, а не оставляйте на словах.
Функциональность и интеграции: проверка действием, а не по скриншотам
Скриншот рабочей формы ничего не говорит о том, куда реально уходит заявка. Я всегда прогоняю сайт через реальные сценарии, а не визуальный осмотр.
- Оформите тестовый заказ через рабочую интеграцию с оплатой (T‑Bank, ЮKassa на WooCommerce или кастомном чекауте) и проверьте, что вебхук подтверждения статуса приходит, а не завис в режиме песочницы.
- Проверьте калькулятор доставки СДЭК на реальных тарифах, а не на захардкоженной сумме «300 рублей по умолчанию», которую часто оставляют для ускорения сдачи.
- Отправьте форму обратной связи и убедитесь, что заявка приходит на вашу почту или в вашу CRM, а не на тестовый адрес разработчика, который забыли поменять.
- Если на Tilda есть кастомные скрипты - попросите переопубликовать страницу на глазах и проверить, что скрипт не слетает после республикации (частая проблема, если код вставлен не через нужный блок).
- Для сценариев с n8n убедитесь, что workflow переведён в статус «Active», а не остался в тестовом режиме, и что настроены уведомления об ошибках выполнения - иначе сбой в цепочке заявка → CRM пройдёт незамеченным.
- Если в проект входил Telegram-бот, проверьте, что он работает на продакшн-сервере через вебхук, а не запущен вручную на ноутбуке разработчика - иначе бот отключится в первый же день после сдачи.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Тестирование на устройствах, скорость и SEO-гигиена
Откройте сайт на разных экранах и в разных браузерах - не только в том, в котором его верстали. Разработчики часто тестируют в Chrome на десктопе и упускают адаптив на узких экранах или Safari на iOS, где по-другому работают фиксированные блоки и видео.
Проверьте базовые технические вещи: скорость загрузки через PageSpeed Insights (для лендинга нормальный ориентир - 70+ баллов на мобильной версии, для интернет-магазина с каталогом планка ниже, но 404 и разрывы контента недопустимы в любом случае), наличие sitemap.xml и корректного robots.txt, заполненные meta-теги вместо «Lorem ipsum» на служебных страницах, отдающиеся favicon и open graph картинки при расшаривании ссылки. Если сайт заменяет старый - проверьте, что настроены 301-редиректы со старых URL, иначе позиции в поиске обнулятся в первые недели после запуска.
Отдельно - интеграции с внешними сервисами
Если в проекте задействован AI-функционал (чат с базой знаний, автоответчик на базе Claude API или OpenAI), проверьте не только что бот отвечает, но и на чьём API-ключе он работает и куда логируются диалоги - ключ должен быть привязан к вашему аккаунту, а не оставаться на балансе разработчика, который через месяц может его отключить.
Документация и передача проекта
Без документации сайт нормально сопровождает только тот, кто его написал - а это ставит вас в зависимость от одного человека. Требуйте на приёмке: список используемых сервисов и API с указанием, на каком аккаунте они оформлены, краткое описание структуры проекта (для кастомной разработки - какие модули за что отвечают), README для нестандартных скриптов и интеграций, инструкцию по обновлению контента в админке.
Если поддержку после сдачи будет вести не тот же разработчик, а вы сами или другая команда, закладывайте время на разбор кода без автора рядом. Часто выгоднее сразу обсудить с текущим подрядчиком техническую поддержку сайта на переходный период - это отдельная услуга, и в стоимость разработки она не входит по умолчанию.
Акт приёмки и юридическая сторона сделки
Акт приёмки - не формальная бумажка для бухгалтерии, а документ, который защищает обе стороны. В нём должно быть зафиксировано:
- Точный перечень выполненных работ - со ссылкой на техзадание или список фич, а не общая фраза «разработка сайта».
- Список переданных доступов и материалов (исходники, дизайн-макеты, контент).
- Гарантийный период на устранение багов - с чёткими границами: что считается багом (несоответствие ТЗ), а что новой доработкой, которая оплачивается отдельно.
- Порядок оплаты остатка - привязан к подписанию акта, а не к обещанию «оплачу через неделю после проверки».
Если часть суммы платится поэтапно, не подписывайте акт закрытия всего проекта, пока не проверили последний этап - частичная приёмка не равна финальной, и это две разные точки в договоре.
Типичные ошибки при приёмке сайта
За годы работы вижу одни и те же грабли у клиентов, которые принимают проекты у других разработчиков:
- Платят 100% до того, как открыли сайт на телефоне - а не только на своём мониторе.
- Не проверяют, на чьём юрлице зарегистрирован домен, пока не понадобится его продлить.
- Верят словам «исходники отправлю после оплаты» - и не получают их вовсе.
- Не тестируют реальные интеграции (оплату, доставку, CRM), ограничиваясь визуальным осмотром вёрстки.
- Подписывают акт с расплывчатой формулировкой работ, из-за которой потом невозможно доказать недоделку.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Сколько времени закладывать на приёмку сайта?
Для лендинга или сайта на Tilda хватает 1-2 дней: проверить формы, адаптив, скорость и доступы. Для интернет-магазина с оплатой и доставкой я закладываю неделю - нужно прогнать несколько тестовых заказов и проверить, что вебхуки от эквайринга и расчёт доставки СДЭК действительно отрабатывают на реальных данных, а не только в демо-режиме. Для веб-сервиса с кастомной логикой сроки приёмки обсуждаются отдельно и завязаны на объём функциональности.
Что делать, если разработчик отказывается передавать доступы?
Зафиксируйте это письменно (переписка, а не устная договорённость) и сверьтесь с договором - обычно передача исходников и доступов после полной оплаты прописана как обязательство подрядчика. Если договора нет или пункта о передаче доступов в нём нет, это стоит учитывать при выборе следующего подрядчика: без письменной фиксации требовать что-либо сложно.
Нужно ли платить 100% до приёмки или после?
Я работаю по схеме предоплата плюс оплата по этапам, а финальный платёж - после подписания акта приёмки, когда клиент лично проверил рабочий сайт на проде, а не на тестовом поддомене. Схема «сначала полная оплата, потом сайт» в вебразработке нормальна только для очень небольших доработок на 3 000-5 000 ₽, где риски обеих сторон минимальны.
Как проверить, что сайт не сломается после ухода разработчика?
Проверьте, что все ключи и токены (платёжные, API нейросетей, СДЭК) привязаны к вашим аккаунтам, а не к личным аккаунтам исполнителя, убедитесь, что есть бэкап базы данных и файлов сайта в вашем распоряжении, и попросите короткую документацию по нестандартным частям проекта. Если своей команды разработки нет, до подписания акта стоит обсудить, кто будет сопровождать сайт дальше - иначе первая же ошибка в логе станет поводом искать нового исполнителя в спешке.