Договор на разработку сайта на тильде

Если вы собираетесь делать сайт на Тильде, сначала остановитесь на минуту и подумайте о договоре. Это не только формальность для бухгалтерии. Хорошо составленный договор спасет вас от недоразумений, растянутых сроков и спорных прав на дизайн. В этой статье я подробно расскажу, какие разделы обязательно включить в договор на разработку сайта на Тильде, какие особенности платформы влияют на формулировки, и дам практичные шаблоны и чек‑листы, которые можно адаптировать под свой проект.

Почему договор важен именно для проектов на Тильде

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

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

Ключевые моменты, которые должен закрывать договор

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

• Предмет договора и точное описание работ.
• Техническое задание и мобильная адаптация.
• Сроки, этапы и критерии приемки.
• Стоимость, расписание платежей и штрафы за просрочку.
• Права на контент, дизайн и исходные материалы.
• Поддержка, сопровождение, гарантийный период.
• Условия использования подписок и оплаты сервисов Тильды.
• Ответственность, конфиденциальность и форс‑мажор.

Почему важно прописывать техническое задание в приложении

Техническое задание — это сердце договора. Чем конкретнее ТЗ, тем меньше споров о том, выполнена ли работа. В ТЗ указывают структуру сайта, количество экранов, блоков, функционал форм, интеграции с почтой и CRM, требования к SEO и аналитике. Лучше приложить к договору скриншоты, ссылки на референсы и карту сайта.

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

Как формулировать предмет договора

Формулировка предмета должна быть конкретной и не оставлять двусмысленности. Пример: «Подрядчик обязуется разработать сайт-визитку на платформе Тильда согласно Техническому заданию (Приложение №1), а Заказчик принять и оплатить выполненные работы в порядке, предусмотренном настоящим договором.»

Укажите явным текстом, что разработка осуществляется на платформе Tilda Publishing. Если предполагается использование zero block, платных шаблонов или интеграций, перечислите их. Это поможет определить, кто оплачивает платные элементы и кто отвечает за лицензионные ограничения.

Примерная структура Технического задания

• Цель сайта и целевая аудитория.
• Структура и количество страниц.
• Описание ключевых блоков и их поведения на мобильных устройствах.
• Формы обратной связи, интеграции с CRM, email-рассылкой, аналитикой.
• Список контента, который предоставляет заказчик, и сроки его передачи.
• Требования к SEO: мета-теги, ЧПУ, карта сайта.
• Критерии приемки: проверка по чек-листу, тестирование форм.

Сроки и этапы работ

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

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

Типичный график работ

Стоимость работ и порядок оплаты

Оплата обычно разбивается на аванс и окончательный расчет. Часто берут 30–50% аванса, остальное поэтапно. В договоре укажите валюту, реквизиты, сроки оплаты после выставления счета и последствия просрочки. Также пропишите, кто оплачивает платные сервисы Тильды и покупные блоки.

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

Пример таблицы оплаты

Приемка работ и исправления

Приемка — не формальность. В договоре стоит прописать понятный алгоритм: сроки на тестирование, порядок фиксации замечаний и срок на их исправление. Например, дать 5 рабочих дней на проверку и 7 рабочих дней на исправление выявленных багов.

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

Пример акта приемки

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

Права на результат и интеллектуальная собственность

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

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

Что нужно учесть по подпискам Тильды

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

Передача доступа и данных

Пропишите, какие данные и доступы будут переданы заказчику по завершении работ: доступ к аккаунту Тильда, доступ к домену у регистратора, доступы к CRM, API-ключи, пароли. Укажите формат передачи — через безопасный канал, в виде протокола передачи доступов. Также определите ответственность за сохранность данных после передачи.

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

Поддержка и сопровождение

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

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

Пример перечня услуг поддержки

• Исправление ошибок функционала — 10 часов в месяц.
• Обновление контента — по согласованной ставке.
• Мониторинг работоспособности форм и интеграций — ежедневная проверка.
• Настройка аналитики и отчетность — ежемесячно.

Гарантии, ответственность и штрафы

Опишите ответственность за нарушение сроков и качество работы. Штрафы — спорный инструмент, но в разумных пределах они стимулируют выполнение сроков. Например, не более 0.1% от стоимости проекта за каждый день просрочки, но не более определенного максимума.

Также укажите предел ответственности сторон — часто подрядчик ограничивает сумму ответственности размерами оплаты по договору. Это стандартная практика, но важно, чтобы ограничение было адекватным и понятным.

Конфиденциальность и обработка персональных данных

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

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

Форс‑мажор и изменения требований

Форс‑мажор следует прописать стандартно: события, которые стороны не могли предвидеть и предотвратить. В договоре указать порядок уведомления о форс‑мажоре и сроки приостановки обязательств.

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

Расторжение договора и последствия

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

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

Советы заказчику: как не допустить ошибок при подписании

• Тщательно проверьте ТЗ. Если что-то смущает, попросите прописать конкретные критерии приемки.
• Оговорите ответственность за платные подписки и лицензионные блоки на Тильде.
• Попросите доступ к черновому сайту на раннем этапе — это удобный способ следить за прогрессом.
• Пропишите обязательства по мобильной адаптации и тестированию на основных браузерах.
• Убедитесь, что в договоре есть пункт о порядке передачи исходных материалов и паролей.

Советы подрядчику: как защитить себя

• Четко формулируйте, что входит и что не входит в стоимость проекта. Это спасет при доработках.
• Ограничьте ответственность и укажите порядок начисления штрафов за просрочку оплаты.
• Держите резервную копию и прописывайте сроки хранения.
• Если используете платные сервисы, оговорите порядок их оплаты и передачу прав.
• Фиксируйте все изменения в дополнительных соглашениях.

Типичные спорные ситуации и как их избегать

Частые конфликты возникают из-за незаконченного ТЗ, неоплаченных доработок, непонимания по подпискам и прав на контент. Решение простое: прописывайте подробно и фиксируйте изменения в документах. Ни один словестный договор не выдержит сравнений с четкими приложениями и актами.

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

Приложения к договору — что включить обязательно

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

• Техническое задание с картой сайта и описанием блоков.
• Макеты или ссылки на макеты в Figma/Sketch.
• Список контента: тексты, изображения, видео и сроки их передачи.
• Чек-лист приемки и тестов.
• Протокол передачи доступов.

Контрольный чек-лист перед подписанием

Образцы формулировок для важных пунктов

Ниже простые, понятные формулы, которые легко адаптировать под свой договор.

Формулировка предмета

«Подрядчик обязуется выполнить разработку сайта на платформе Tilda в объеме, описанном в Приложении №1, а Заказчик обязуется принять и оплатить выполненные работы в порядке и сроки, установленные настоящим договором.»

Формулировка о правах

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

Формулировка о гарантиях

«Подрядчик предоставляет гарантийный период 30 календарных дней на исправление багов, обнаруженных в результате использования сайта по назначению. Исправления, вызванные изменением требований Заказчика, оплачиваются отдельно.»

Когда стоит обратиться к юристу

Если проект крупный, включает персональные данные, сложные интеграции с CRM или большие бюджеты, имеет смысл привлечь юриста для проверки договора. Это не про бюрократию — это про ясность и снижение рисков. Юрист поможет корректно сформулировать пункты о правах, ответственности и обработке данных.

Но для большинства небольших проектов достаточно четкого типового договора с подробным ТЗ и приложениями. Главное — не экономить на деталях, если вы хотите спокойствия в процессе разработки.

Коротко: шаблонный список обязательных пунктов

1. Реквизиты и данные сторон.
2. Предмет договора.
3. Техническое задание как приложение.
4. Сроки и этапы работ.
5. Стоимость и порядок оплаты.
6. Порядок приемки и акт передачи.
7. Права на результаты работ.
8. Поддержка и сопровождение.
9. Ответственность и форс‑мажор.
10. Порядок расторжения и урегулирования споров.

Заключение

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

Если вы фрилансер, используйте договор как способ защитить свой труд. Если вы заказчик, запрашивайте подробное ТЗ и четкие сроки. В итоге все будут спокойнее, а сайт — быстрее в рабочем состоянии.

Полезная ссылка: Договор на разработку сайта на тильде