Акт к договору на разработку сайта (ПО)

1. Что закрывает акт по разработке сайта?

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

Разработка отличается от обычного подряда одной вещью: результат здесь — объект авторского права. Программы для ЭВМ охраняются как литературные произведения, а сайт — как составное произведение, объединяющее тексты, графику, дизайн и код.

Отсюда двойной предмет передачи. Первое — сам результат: файлы, исходный код, макеты, база данных. Второе — исключительное право на него, то есть возможность использовать произведение любым способом и распоряжаться этой возможностью.

Разница между ними — источник большинства споров в этой сфере. Заказчик оплатил разработку, получил работающий сайт и уверен, что он его. Юридически это не так: файлы переданы, а права могли остаться у исполнителя.

Конструктор на этой странице спрашивает статус заказчика и исполнителя, тип объекта, соответствие результата договору, соблюдение срока, способ передачи и стоимость. Блок про права выносят в договор, а в акте дублируют — так его труднее оспорить. Типовой образец 2026 года такой блок уже содержит.

2. Кому принадлежат права на разработку?

Это главный вопрос всей темы, и ответ на него зависит от того, что написано в договоре.

Общее правило для произведения, созданного по заказу: исключительное право принадлежит заказчику, если договором между подрядчиком и заказчиком не предусмотрено иное. Но для договора, предметом которого не было создание произведения, правило обратное — право остаётся у исполнителя, а заказчик вправе использовать результат лишь в целях, для которых заключался договор.

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

• полное отчуждение исключительного права заказчику;
• предоставление лицензии с указанием способов использования;
• исключительная лицензия, когда исполнитель сам использовать результат не может;
• неисключительная лицензия, допускающая повторное использование наработок;
• срок и территория действия лицензии;
• право заказчика дорабатывать и модифицировать результат.

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

Отдельно существуют личные неимущественные права автора: право авторства и право на имя. Они неотчуждаемы и остаются у конкретного человека, написавшего код. Передать их нельзя даже по соглашению, и это нормально: они не мешают заказчику использовать результат.

3. Техническое задание как критерий приёмки

Форма спрашивает, соответствует ли результат работ договору. Чтобы на этот вопрос можно было ответить честно, нужно техническое задание — и составленное так, чтобы соответствие проверялось.

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

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

Последний пункт недооценивают. Явно записанное «наполнение контентом, настройка рекламных кампаний и техническая поддержка в объём не входят» снимает вопрос до того, как он возникнет.

При приёмке идут по заданию строка за строкой и результат фиксируют в акте. Формулировка «результат соответствует техническому заданию от 20 января 2026 года, проверка проведена по всем пунктам» весит больше, чем «работы выполнены надлежащим образом».

4. Что именно должно быть передано заказчику?

Отдельный вопрос формы — способ передачи результата. Он важнее, чем кажется: работающий сайт и полностью переданный проект — это разные вещи.

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

• исходный код в полном объёме, с историей репозитория;
• инструкция по сборке и развёртыванию;
• исходные файлы дизайна в редактируемом формате;
• структура и дамп базы данных;
• доступы: хостинг, домен, панель управления, почта, аналитика;
• документация: архитектура, руководство администратора и пользователя.

Домен — отдельная история. Он не является объектом авторского права и передаётся не по акту, а сменой администратора у регистратора. Проверить, на кого зарегистрирован домен, стоит до подписания.

Способ передачи фиксируют конкретно: архив на носителе, ссылка на репозиторий с датой предоставления доступа, передача учётных данных по защищённому каналу. «Переданы в электронном виде» слишком расплывчато, чтобы что-то доказывать. В хорошем шаблоне под перечень передаваемых объектов отведена таблица, а не одна строка: заполнять её дольше, но именно она потом работает.

5. Чужие компоненты внутри вашего сайта

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

Правило простое и жёсткое: никто не может передать больше прав, чем имеет сам. Исполнитель, использовавший чужую библиотеку, передаёт заказчику права на свой код, но не на неё.

Часть компонентов распространяется свободно, часть — на условиях, которые накладывают обязательства и на конечного пользователя. Некоторые лицензии требуют раскрывать производный код, другие запрещают коммерческое использование, третьи обязывают указывать автора.

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

Шрифты и фотографии — самая частая мина. Изображение, купленное разработчиком по личной подписке для одного проекта, не переходит к заказчику вместе с сайтом. Через год приходит претензия от правообладателя, и объяснить её происхождение уже некому.

Поэтому перечень сторонних компонентов оформляют приложением к акту. Это не бюрократия: без него заказчик не знает, что именно он вправе использовать, а что взято во временное пользование исполнителя.

Форму такого перечня удобно утвердить один раз: типовой бланк с колонками «компонент», «версия», «лицензия», «ограничения». Скачать заготовку и заполнять её по ходу проекта проще, чем восстанавливать список за неделю до сдачи.

6. Кто автор, если код писала команда?

Разработку почти никогда не делает один человек. И у каждого участника возникают собственные авторские права на созданную им часть — если, конечно, отношения не оформлены правильно.

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

Когда привлекают фрилансеров по гражданско-правовым договорам, права должны переходить к студии по этим договорам. Если такого условия нет, студия физически не может передать заказчику то, чего у неё нет.

Отсюда полезное условие в договоре: исполнитель гарантирует, что обладает всеми правами, необходимыми для их передачи заказчику, и обязуется урегулировать претензии третьих лиц самостоятельно. Такая гарантия не заменяет проверку, но перекладывает риск.

Для заказчика практический вывод: спрашивайте, кто именно писал код и как оформлены отношения с этими людьми. Ответ «у нас все в штате» проверяется одной фразой в договоре о служебном характере произведений.

7. Сроки, этапы и что делать при просрочке

Форма отдельно спрашивает, выполнены ли работы в установленный срок. Для разработки этот вопрос актуальнее, чем для многих других видов подряда.

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

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

• сроки этапов с описанием результата каждого;
• срок на предоставление заказчиком материалов и обратной связи;
• порядок сдвига сроков при задержке со стороны заказчика;
• количество итераций правок, входящих в стоимость;
• неустойка за просрочку и её база расчёта;
• срок тестирования и приёмки на стороне заказчика.

Количество итераций правок — специфика именно разработки. Без ограничения дизайн можно переделывать бесконечно, и срок сдвигается по вине обеих сторон. Условие «три круга правок на каждом этапе, последующие оплачиваются отдельно» дисциплинирует всех.

Задержка обратной связи от заказчика — вторая по частоте причина срыва сроков. Условие о том, что при отсутствии ответа в течение пяти рабочих дней этап считается согласованным, решает проблему без конфликта.

8. Приёмка результата и гарантия на код

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

Правило же действует общее. Заказчик, обнаруживший недостатки при приёмке, вправе ссылаться на них только тогда, когда они оговорены в акте либо в нём записана возможность предъявить требования позже. А принявший работу без проверки теряет право ссылаться на то, что можно было заметить.

Для разработки это означает, что тестирование проводят до подписания, а не после. Причём по заранее согласованным сценариям, а не «покликаем и посмотрим».

• прохождение согласованных тестовых сценариев;
• проверка на целевых браузерах и устройствах;
• поведение при некорректном вводе и на граничных значениях;
• скорость загрузки на реальном объёме данных;
• работа интеграций со сторонними сервисами;
• полнота переданных исходников и доступов.

Гарантийный срок на разработку устанавливают договором — обычно от трёх месяцев до года. В его пределах исполнитель бесплатно устраняет ошибки, возникшие по его вине, и доказывать причину заказчику не нужно.

Границу гарантии описывают отдельно. Исправление ошибок в переданном коде входит в гарантию; доработка новых функций, устранение проблем после чужого вмешательства и сбои по вине хостинга — нет. Без такого разграничения гарантия превращается в бесплатную поддержку. В типовом образце 2026 года границы гарантии обычно вынесены отдельным абзацем — переписывать их под себя проще, чем формулировать с нуля.

9. Оплата, этапы и что бывает при отказе

Конструктор спрашивает о стоимости работ, а порядок расчётов определяется договором. В разработке распространены три схемы, и у каждой своя логика.

Фиксированная цена за весь проект подходит, когда задание проработано детально. Поэтапная оплата — когда проект длинный и разбит на понятные вехи. Почасовая оплата — когда объём заранее неизвестен и стороны доверяют друг другу.

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

Отдельно стоит описать, что происходит при досрочном прекращении. Заказчик вправе в любое время до сдачи результата отказаться от договора, уплатив исполнителю часть цены пропорционально выполненной работе и возместив убытки в пределах разницы между ценой договора и уплаченным.

Для разработки это означает вопрос: что заказчик получает при отказе на середине? Разумное условие — передача выполненной части вместе с правами на неё пропорционально оплате. Без такого условия заказчик платит, но не получает ничего пригодного к использованию.

10. Государственная регистрация программы

Для программ для ЭВМ и баз данных существует возможность добровольной государственной регистрации, и вопрос о ней иногда возникает при приёмке.

Регистрация не создаёт права: оно возникает с момента создания произведения независимо от каких-либо формальностей. Свидетельство лишь облегчает доказывание авторства и даты создания.

Практический смысл появляется в двух случаях. Первый — когда программу планируют лицензировать или продавать: наличие свидетельства упрощает сделки. Второй — когда велик риск копирования: зарегистрированный депозит кода фиксирует его содержание на конкретную дату.

Важная деталь: договор об отчуждении исключительного права на зарегистрированную программу подлежит государственной регистрации. Если программа зарегистрирована, а переход права — нет, формально право к заказчику не перешло.

Поэтому при работе с зарегистрированными программами вопрос «кто и когда регистрирует переход права» решают в договоре, а в акте фиксируют, что документы для регистрации подготовлены и переданы.

11. Отчуждение права и лицензия: что выбрать

Выбор между двумя моделями определяет и цену разработки, и то, что заказчик сможет делать с результатом дальше.

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

12. Персональные данные и безопасность

Сайт с формой обратной связи или личным кабинетом собирает персональные данные, и ответственность за их обработку лежит на владельце сайта, а не на разработчике.

Разработчик при этом обязан обеспечить техническую сторону: наличие форм согласия, ссылок на политику обработки, возможность отзыва согласия и удаления данных. Эти требования включают в задание, а их выполнение проверяют при приёмке.

• формы согласия на обработку данных на всех страницах со сбором;
• размещённая политика обработки персональных данных;
• уведомление об использовании файлов cookie;
• хранение данных на серверах, размещённых на территории страны;
• разграничение прав доступа в административной части;
• передача учётных данных по защищённому каналу, а не в переписке.

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

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

13. Что писать в акте про права

Блок про права — то, ради чего этот акт отличается от обычного акта выполненных работ. Формулировки здесь должны быть однозначными.

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

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

• какой именно результат передаётся: перечень объектов;
• модель: отчуждение или лицензия;
• момент перехода права или начала действия лицензии;
• способы использования, если это лицензия;
• гарантия исполнителя об отсутствии прав третьих лиц;
• приложение с перечнем сторонних компонентов и их лицензий.

Момент перехода стоит привязать к оплате, если она поэтапная. Формулировка «право переходит после полной оплаты» защищает исполнителя, а «право переходит с момента подписания акта» — заказчика. Договариваться об этом лучше до начала работ.

14. Реквизиты, подписи и экземпляры

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

Шапка выглядит так: «Акт сдачи-приёмки № 3 от 14 марта 2026 года к договору на разработку сайта № 9 от 20 января 2026 года». Если работы сдаются этапами, номер этапа указывают тоже.

• полные данные сторон, для организаций — ИНН, ОГРН и адрес;
• наименование результата: название сайта, программы, доменное имя;
• ссылка на техническое задание с его датой;
• перечень переданных объектов и способ передачи;
• блок о правах на результат;
• стоимость, отметка о налоге и порядок расчётов;
• гарантийный срок, наличие замечаний и подписи с расшифровками.

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

Экземпляров делают два, а при регистрации перехода права — три. Хранить документ нужно бессрочно: он подтверждает основание владения активом, и понадобиться может через много лет, при продаже бизнеса или при споре о правах. Электронный образец с квалифицированными подписями хранится столько же и удобнее в поиске.

15. Какие ошибки допускают чаще всего?

Ошибки в актах по разработке дороже большинства других: они обнаруживаются не сразу, а в момент, когда актив понадобился для сделки или для смены подрядчика.

• про права не сказано ничего — считается, что они остались у исполнителя;
• лицензия предоставлена без права переработки;
• не передан исходный код, только собранная версия;
• домен зарегистрирован на разработчика и не переоформлен;
• нет перечня сторонних компонентов и их лицензий;
• нет ссылки на техническое задание, и соответствие проверить не с чем;
• не зафиксирован список переданных доступов;
• замечания по тестированию высказаны устно;
• гарантия описана общей фразой без границ ответственности.

Отдельная ошибка — считать, что оплата автоматически означает переход прав. Логика «я заплатил, значит, моё» в авторском праве не работает: право переходит только по прямо выраженному условию.

Ещё одна — использовать обычный акт выполненных работ без блока о правах. Для физической работы он подходит, для разработки — нет: главное в такой сделке остаётся неоформленным.

16. Образец, бланк или конструктор?

Разница между тремя вариантами измеряется временем, которое уйдёт на доводку файла под конкретный проект.

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

Форма на этой странице уточняет статус заказчика и исполнителя, тип объекта, соответствие результата договору, соблюдение срока, способ передачи результата и стоимость работ. Собранный типовой образец сразу можно скачать.

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

Основанием для акта служит договор подряда, а сроки этапов удобно вынести в календарный план работ: разработка почти всегда делится на вехи, и контролировать их по плану проще.

17. Быстрая проверка перед подписью

Четверть часа перед подписью окупается многократно — особенно если проект придётся передавать другому подрядчику.

• есть ссылка на договор и на техническое задание с датами;
• результат проверен по всем пунктам задания;
• блок про права заполнен и соответствует договорённостям;
• исходный код получен и открывается;
• все доступы переданы и проверены на работоспособность;
• домен зарегистрирован на заказчика;
• приложен перечень сторонних компонентов с лицензиями;
• указан гарантийный срок и границы гарантии;
• замечания по тестированию внесены в акт до подписи;
• полномочия подписантов подтверждены, экземпляров достаточно.

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

18. Коротко о главном

Акт по разработке сайта или программы закрывает две вещи одновременно: передачу самого результата и передачу прав на него. Второе важнее и оформляется хуже.

• оплата разработки сама по себе прав на результат не переносит;
• модель — отчуждение или лицензия — выбирают до начала работ;
• право на переработку прописывают отдельной строкой;
• соответствие проверяют по техническому заданию, а не «на глаз»;
• исходный код, доступы и домен передают и фиксируют перечнем;
• сторонние библиотеки, шрифты и фотографии перечисляют с лицензиями;
• замечания вносят в акт до подписи, устные обещания не работают.

Форма выше делает всю сборку за вас: несколько ответов — и готовый бланк 2026 года можно скачать, распечатать и подписать. Отдельный образец под каждый этап проекта собирается за минуту.

Автор статьи: Мария Губина (юрист)