Приёмка сайта и приложения у подрядчика: 24 пункта, по которым видно брак

Чек-лист из 24 пунктов для приёмки сайта и приложения: признаки брака, нормы статей 720, 723 и 1296 ГК РФ, пороги скорости и наши замеры с живого прода.

Коротко

Материал актуален на 05.10.2026. Приёмка сайта и приложения заказчиком — это не подпись под словами «всё работает», а проверка по измеримым критериям: что кликнуть, что замерить и каким числом должен заканчиваться каждый пункт.

• Закон даёт рамку, но не чек-лист. По ст. 720 ГК РФ заказчик обязан осмотреть результат с участием подрядчика, а недостатки, не оговорённые в акте приёмки, позже почти невозможно вменить.
• Ниже — чек-лист приёмки из 24 пунктов в шести группах: документы, функциональность, контент и SEO, скорость и мобильные, безопасность и доступы, процесс сдачи. У каждого пункта есть признак нарушения.
• Цифры, которые мы измерили на собственном сайте: серверный HTML 11 маршрутов — 4 207–4 606 B при нуле слов; GET /api/blog без сессии — 2 226 837 B; og-image.png — 2 210 909 B.
• Проект принят, когда проверки прогнаны: в нашем кейсе про AI-продукт это 16 из 16 функциональных проверок и 33 из 33 визуальных снимков, а незакрытое помечено «не проверено», а не «почти готово».
• Своими силами реально пройти curl с ботовым агентом, DevTools на 390 px, Lighthouse, формы и админку. Код, нагрузочное тестирование и споры — территория разработчика или независимого аудитора.

Почему демо и слова «всё работает» — не приёмка?

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

Мы знаем обе стороны прилавка: студия сама сдаёт проекты и сама принимает свои AI-продукты по измеримым критериям. В октябре 2026 года мы пересняли собственный прод и нашли на нём ровно те дефекты, которые обычно ищем у подрядчиков. Эти замеры — ниже, без ретуши.

Пример, почему условия приёмки важнее демонстрации: срез обложки статьи зависит от ширины экрана и на 1920 px доходит до 25,2 % кадра с каждой стороны, а на телефоне 390 px кадр влезает почти целиком. Мобильный скриншот дефект не показывает, и приёмка «по телефону» его пропускает.

Приёмка начинается раньше подписания акта — с выбора исполнителя: вот 12 критериев выбора AI-подрядчика.

Что говорит закон: приёмка работ по ГК РФ

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

• Статья 720 ГК РФ (часть вторая Кодекса в ред. от 24.06.2025). Пункт 1: заказчик обязан в сроки и в порядке, которые предусмотрены договором подряда, с участием подрядчика осмотреть выполненную работу. Пункт 2: ссылаться на недостатки, обнаруженные позже, можно, только если «в акте либо в ином документе, удостоверяющем приемку, были оговорены эти недостатки». Пункт 3: заказчик, принявший работу без проверки, «лишается права ссылаться на недостатки работы, которые могли быть установлены». Пункт 5: при споре о качестве назначается экспертиза, и «расходы на экспертизу несет подрядчик», если не доказано отсутствие его вины.
• Статья 723 ГК РФ. Работа выполнена с отступлениями, ухудшившими результат? Заказчик выбирает: безвозмездное устранение недостатков в разумный срок, соразмерное уменьшение цены или возмещение своих расходов на устранение (п. 1). Если недостатки существенные и неустранимые либо не устранены в разумный срок, заказчик вправе отказаться от договора и потребовать возмещения убытков (п. 3).
• Статья 783 ГК РФ. К договору возмездного оказания услуг — например, на поддержку и доработку — применяются общие положения о подряде (статьи 702–729), если это не противоречит статьям 779–782 и особенностям предмета. То есть приёмка по договору услуг возвращается к той же ст. 720.
• Статья 1296 ГК РФ (часть четвёртая, статья в ред. от 12.03.2014): «Исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору, предметом которого было создание такого произведения (по заказу), принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное».

Вывод простой: права у заказчика есть, но порядок — сроки осмотра, форму акта, перечень проверок — задаёт договор. Чего нет в договоре и в акте, то потом доказывается через экспертизу.

Как мы принимаем собственный прод: замеры 04.10.2026

Перед тем как отдать разработчику ТЗ на правки, мы пересняли числа с живого прода, а не из старых отчётов. Правило такое: замер для приёмки свежий, и к каждому числу прилагается способ его воспроизвести. Вот что мы измерили на artifica.tech через curl, headless-браузер и DevTools.

Ещё две находки, которые не измеряются байтами. Первая: после гидрации в DOM остаётся служебный <article id="__seo__"> с полным телом статьи — второй экземпляр текста рядом с видимым.

Вторая: вертикальный срез обложки зависит от вьюпорта. По нашему расчёту, при кадре 1280×720 и высоте героя 500 px масштаб равен W/1280, а срез с каждой стороны — половина разности (720·W/1280 − 500), отнесённая к отрисованной высоте. При вьюпорте 1440 это 16,1 %, при 1600 — 19,8 %, при 1920 — 25,2 %. Формула проверяется в DevTools: на десктопе первая строка заголовка обложки была отрезана ровно по середине знаков.

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

Что должно быть в документе на исправление?

Дефект, найденный на приёмке, превращается в правку только тогда, когда подрядчик может его воспроизвести, а вы — проверить исправление. Своё ТЗ на код-правки мы строим так же и вам советуем требовать этого от подрядчика.

• Свежий замер и «как воспроизвести» в каждом пункте. Число без команды или пути в DevTools превращается в спор о вкусах.
• Приоритеты. P0 — блокирует продвижение или несёт риск, P1 — заметно влияет, P2 — гигиена. Порядок работ вытекает из приоритетов и зависимостей.
• Критерий приёмки на пункт. Не «сделать быстро», а например: при 390 px scrollWidth равен clientWidth, таблица скроллится внутри обёртки.
• Раздел «чего трогать нельзя». Контентные поля, контракты админки, принятая модель рендеринга — чтобы правка не сломала соседнее.
• Рискованные проверки — на staging. Писать ли API без авторизации, нельзя проверять на проде с реальными лидами; в ТЗ такая формулировка стоит прямо.
• Итоговый чек-лист команд, запускаемых с локалки после выката. В нашем ТЗ их 11: пререндер, каноник, заголовки безопасности, дампы, разметка, мобильная таблица.

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

Чек-лист приёмки: 24 пункта, по которым видно брак

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

Документы

1. В договоре есть измеримые критерии приёмки на каждую задачу. Признак: задача сформулирована как «красиво и удобно», числа или команды для проверки нет.
2. Сроки и порядок осмотра зафиксированы. Признак: в договоре нет ни срока приёмки, ни формата, в котором оформляются замечания.
3. Исключительное право на код — у заказчика (ст. 1296 ГК РФ). Признак: договор молчит о правах на программу либо право оставлено за исполнителем.
4. Замечания вписаны в акт, а не в мессенджер. Признак: акт подписан чистым, а договорённости об исправлениях живут только в переписке.

Функциональность

5. Основной сценарий работает без разработчика. Форма → заявка там, где обещано: в CRM, почте, админке. Признак: заявка не приходит или падает в неизвестную таблицу.
6. Формы сообщают об ошибках. Признак: форма «отправляется», и не происходит ничего — пользователь не узнаёт, что поле не заполнено.
7. Страница не улетает при сбое данных. Признак: статья или карточка товара редиректит на главную при недоступном API. Мы такой дефект на своём проде ловили.
8. Несуществующий адрес отдаёт 404. Признак: любой URL отвечает 200 с той же обёрткой — для поисковика это мягкий 404.

Контент и SEO

9. Серверный HTML содержит текст. Проверка — curl с ботовым агентом. Признак: ответ 4–5 KB, слов ноль, <h1> нет — как на наших 11 маршрутах до пререндера.
10. canonical есть и указывает на саму страницу. Признак: тега нет в серверном HTML либо он ведёт на соседний раздел — у нас каноник с /cases показывал на /blog.
11. Мета сервера и браузера совпадают. Признак: title с сервера отличается от того, что подставляет JS, — поисковик и человек видят разные страницы.
12. Социальные превью собираются. Признак: og:image весит мегабайты, twitter-карточек нет — ссылка в мессенджер уходит текстом без картинки.

Скорость и мобильные

13. LCP не выше 2,5 с на мобильном замере. Признак: в нашем аудите скорости коммерческого сайта LCP был 12,5 с при FCP 7,9 с.
14. Вес страницы и формат картинок согласованы. Признак: галерея отдаётся оригиналами PNG — 8 файлов на 9 086 359 B, по нашему расчёту около 77 % веса страницы.
15. При 390 px нет горизонтального скролла. Проверка: documentElement.scrollWidth равен 390. Признак: 579 и выше — вёрстку распирает таблица или блок.
16. Таблицы скроллятся внутри обёртки. Признак: четырёхколоночная таблица растягивает всю страницу вместо скролла внутри себя.
17. www и домен без www работают с валидным HTTPS. Признак: на www ошибка TLS, а http://www отдаёт 404 — наш собственный случай, унесённый в ТЗ.

Безопасность и доступы

18. API не пишет данные без сессии. Проверка — только на staging. Признак: POST без cookie отвечает 200 и меняет записи.
19. Публичных дампов нет. Признак: GET /api/blog без авторизации отдаёт всю базу — у нас это были 2 226 837 B.
20. Вход в админку защищён от перебора, заголовки безопасности заданы. Признак: 8 неверных паролей подряд дают 8 ответов 401 без задержки и блокировки.
21. Доступы переданы заказчику. Домен, хостинг, репозиторий, аналитика, почта, сертификаты. Признак: в контактах сайта личный ник и телефон подрядчика.

Процесс сдачи

22. Подрядчик сдаёт отчёт о приёмке с числами. Признак: вместо отчёта — лог деплоя с «ошибок: 0» и слова «всё работает».
23. Отклонения от ТЗ задокументированы в GAP-отчёте. Признак: эталонный стек подменён молча — без причины и пути возврата.
24. Регресс прогнан повторно после любой переделки. Признак: после редизайна или смены темы проверки никто не перезапускал.

Какие ошибки заказчик совершает чаще всего?

• Подписывает акт до проверок. Пункты 2 и 3 ст. 720 ГК РФ потом работают против вас: чтобы вменить неоговорённые недостатки, придётся доказывать, почему их нельзя было оговорить.
• Принимает на демо-стенде. Прод отличается данными, нагрузкой и настройками: что летало на машине подрядчика, то тормозит на вашей.
• Верит логам вместо HTML. Наше правило приёмки: правка принята, если новые формулировки возвращаются в серверном HTML с ботовым агентом, а снятые — не возвращаются. Лог выгрузки с «ошибок: 0» приёмкой не считается.
• Не фиксирует условия замера. В аудите скорости бандл весил 774,35 КиБ в отчёте от 30 сентября и 793 164 B в прямом замере 1 октября: сайт пересобрали между замерами. Оценка эффекта на устаревшем файле обещает не то.
• Оставляет аккаунты у подрядчика. После оплаты домен, хостинг и аналитика переводятся на аккаунты заказчика, пароли меняются.

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

Когда можно считать, что проект принят?

Когда у каждого критерия есть порог, а у порога — протокол прогона. Вот значения, по которым работаем мы: часть взята из кейса о приёмке AI-продукта, часть — из ТЗ на скорость сайта. Цели по весу и запросам ставились под конкретный проект — вашим могут подойти другие, но принцип один: порог согласован до старта работ.

В кейсе про AI-продукт приёмка встроена в сам продукт: 16 из 16 функциональных проверок на реальном pipeline импорта и 33 из 33 визуальных снимка в headless-браузере. После переделки интерфейса прогон повторили — снова 16 из 16 и 33 из 33. Подробности — AI-продукт с приёмкой 16 из 16 и 33 из 33.

В аудите скорости 26 пунктов ТЗ легли так: 6 блокирующих, 13 важных, 7 улучшений; на каждый пункт — данные, критерий приёмки и ожидаемый эффект. Клиент и домен не названы, замера «после» на момент публикации нет, поэтому все эффекты помечены как ожидаемые: технический аудит скорости коммерческого сайта. Разбор методики — в статье что чинить первым, если LCP 12,5 секунды.

Что проверить самому, а где позвать аудитора?

Честная граница самопомощи. Без разработчика и бюджета вы пройдёте примерно половину чек-листа:

• curl с агентом YandexBot или Googlebot — посчитать слова и <h1> в серверном HTML.
• DevTools на 390 px — сравнить scrollWidth с clientWidth, посмотреть таблицы и обложки.
• Lighthouse в эмуляции телефона — снять LCP, FCP и вес страницы.
• Основной сценарий руками: форма, оплата, регистрация, заявка в админке.
• Сертификат на www, вес og:image через HEAD-запрос, код ответа на несуществующий адрес.

Где нужен специалист: аудит кода и репозитория, нагрузочное тестирование, проверка безопасности, миграция без простоев. А если спор уже в стадии «подрядчик не признаёт брак», п. 5 ст. 720 ГК РФ предусматривает экспертизу — её проводят не маркетологи. За независимой технической оценкой приходите на AI-консалтинг и аудит: раскладываем проект по слоям и выдаём ТЗ на правки с критериями приёмки.

Как мы помогаем с приёмкой и что сделать дальше?

Мы принимаем проекты по обе стороны прилавка. Как исполнитель — сдаём работу с протоколом приёмки и числами. Как заказчик своих же продуктов — переснимаем прод и пишем ТЗ с командами воспроизведения. Оба кейса выше внутренние: в них нет придуманных клиентов, отзывов и метрик «после», которых не существует.

Если вы сейчас принимаете сайт или приложение, напишите нам через страницу контактов. Мы посмотрим договор и ТЗ, вернём чек-лист приёмки, адаптированный под ваш проект: с командами, порогами и шаблоном акта, где у каждого замечания есть признак нарушения. Отдельной строки в прайсе на приёмочный аудит нет — объём и стоимость считаем после того, как увидим документы.