Многие руководители при подписании договора на разработку сайта сосредоточены на стоимости и сроках, а в графе результатов работ пишут наспех: «сайт в комплекте, исходный код в комплекте». И только после завершения проекта выясняется: дизайн-макеты не отдают, доступ к админ-панели у исполнителя, сервер оформлен на его имя, а за замену баннера нужно платить отдельно.
Дело не в чьей-то злой воле — просто договор составлен нечётко. Чем конкретнее описаны результаты работ, тем меньше проблем в дальнейшем. Ниже разбираем пять категорий, и для каждой даём формулировки, которые можно взять за основу.
1. Исходный код и пакет развёртывания: пропишите «что передаётся и как»
Исходный код — самый расплывчатый пункт. Рекомендуем зафиксировать в договоре три вещи: какие именно части кода передаются, в какой форме и сможет ли заказчик запустить проект самостоятельно после передачи.
Рабочая формулировка: исходный код фронтенда, исходный код бэкенда, файл структуры базы данных, документация по развёртыванию — передаются единым пакетом, с условием, что после передачи заказчик может самостоятельно развернуть и запустить проект на собственном сервере.
Есть две типичные ловушки. Первая — указано «предоставляется исходный код», но не указана структура базы данных, и полученный код не запускается. Вторая — в коде используются собственные приватные компоненты или зашифрованные файлы исполнителя: формально код передан, но фактически без исполнителя не обойтись. В проектах вроде корпоративного сайта это особенно важно: так называемый исходный код многих шаблонных сайтов на деле представляет собой вторичную обёртку с лицензионными ограничениями.
Если речь о разработке мини-программы, дополнительно пропишите: аккаунт主体 мини-программы принадлежит заказчику, код может быть загружен в собственный панель разработчика заказчика.
2. Дизайн-макеты и материалы: не ограничивайтесь скриншотами
В результатах работ по дизайну рекомендуем указать: редактируемые исходные файлы (например, Figma, Sketch или PSD), нарезанные графические ресурсы, инструкцию по использованию шрифтов и иконок.
Отдать только JPG-скриншот — значит не отдать ничего. При смене дизайнера или расширении под акционные страницы всё придётся перерисовывать.
Также зафиксируйте принадлежность прав на материалы: можно ли коммерчески использовать изображения, шрифты и иконки, применённые исполнителем, и кто несёт ответственность при возникновении спора о правах. Этот пункт в проектах разработки сайтов часто упускают, но если проблема действительно возникнет — это прямая блокировка и снятие сайта.
3. Домен, сервер, аккаунты: право собственности должно быть закреплено жёстко
Это зона повышенного риска споров. В договоре следует указать: домен регистрируется на имя заказчика, сервер или облачный аккаунт приобретается заказчиком на своё имя, исполнитель сохраняет лишь необходимые права доступа на время разработки и сопровождения.
Конкретный сценарий: одна компания делала редизайн корпоративного сайта и по завершении обнаружила, что домен находится у предыдущего подрядчика — продление за доплату, переезд только с его содействием, задержка на месяц.
Поэтому в перечне результатов работ нужно указать: аккаунт управления доменом, аккаунт облачного сервера, аккаунт базы данных, аккаунт администратора админ-панели, информацию о регистрации (ICP), аккаунты и ключи сторонних сервисов (SMS, платежи, карты). При передаче — сверка по пунктам и подпись.
4. Админ-панель и документация: результат считается переданным, только если им можно пользоваться
Передача системы управления — это не только аккаунт, но и: перечень функций, описание полей, описание ролей и прав, руководство по типовым операциям.
Рекомендуем предусмотреть одно онлайн- или офлайн-обучение при передаче и сохранить видеозапись. Тогда при смене персонала новые сотрудники смогут разобраться самостоятельно.
Для разработки приложений и сложных проектов с админ-панелью также стоит требовать документацию по API и историю версий — для последующей интеграции с другими системами.
5. Критерии приёмки: превратите «работает» в измеримые пункты
Условия приёмки должны быть исполнимыми. Рекомендуем прописать: поэтапную приёмку функций согласно документу требований, перечень поддерживаемых браузеров и моделей устройств, предельное время загрузки страницы, базовые пункты тестирования безопасности сайта (например, проверка на типовые инъекции, обход прав доступа, раскрытие конфиденциальной информации).
Одновременно зафиксируйте период устранения дефектов и сроки реакции, а также количество раундов доработки при непрохождении приёмки.
Ловушка: не пишите «по усмотрению заказчика» и не используйте нечто непроверяемое вроде «соответствует отраслевым стандартам».
В каких случаях стоит обратиться в MIC Studio
Если вы находитесь в одной из следующих ситуаций, можете обсудить проект с нами: требования уже продуманы и нужен реализуемый перечень результатов работ; существующую систему нужно подвергнуть обратному тестированию или проверке безопасности; либо в штате нет профильных специалистов, но вы хотите, чтобы аккаунты, исходный код и документация оставались у вас.
Мы занимаемся корпоративными сайтами, разработкой мини-программ, разработкой приложений и разработкой скриптов, а также выполняем тестирование безопасности. На этапе договора мы оформляем результаты работ в виде таблицы и подписываем её как приложение — чтобы избежать повторных объяснений в дальнейшем.
Три практические рекомендации
1. Оформите результаты работ как таблицу-приложение с пунктами «наименование, форма, срок передачи, способ приёмки» и подпишите её.
2. До подписания договора уточните, на чьё имя оформлены домен и облачный аккаунт; если не на ваше — сначала выполните перенос, затем обсуждайте разработку.
3. Привяжите долю финального платежа к приёмке: оставьте 10–20% к выплате после завершения обучения при передаче и сверки аккаунтов без расхождений.
Детальный договор — это не недоверие, а способ сэкономить время обеих сторон на объяснениях.