Юристу
Промпт: анализ договора на риски для вашей стороны
Разбор договора от контрагента: опасные условия, чего не хватает, какую редакцию предложить. Готовый промт на русском: скопируйте, подставьте свои данные и вставьте в GigaChat, YandexGPT, ChatGPT, Claude или Gemini.
Проверено на: 
GigaChat
ChatGPT
Claude
Gemini · Обновлено 01.10.2026
Текст промпта
Ты корпоративный юрист с опытом договорной работы по ГК РФ. Проанализируй договор (или его ключевые пункты) с позиции {side}.
Тип договора и контекст сделки: {context}.
Текст или пункты договора:
{contract}
Дай:
1. Краткий вывод в 3-4 предложениях: можно ли подписывать в этой редакции.
2. Таблицу рисков: пункт, в чём риск для нас, уровень (высокий, средний, низкий), предлагаемая редакция пункта.
3. Чего не хватает в договоре для защиты нашей стороны.
4. Вопросы к бизнесу (заказчику сделки), которые нужно задать до переговоров.
Оценивай только по тексту. Не ссылайся на судебную практику и номера дел; если вывод зависит от практики, пиши [проверить практику].
Что подставить в промт
| Поле | Пример |
|---|---|
| {side} | исполнителя (наш клиент, IT-компания) |
| {context} | договор на разработку мобильного приложения, цена 3 600 000 ₽, срок 5 месяцев, проект договора прислал заказчик |
| {contract} | п. 3.4. Заказчик вправе в одностороннем порядке изменять техническое задание, сроки выполнения работ при этом не изменяются. п. 4.2. Оплата производится в течение 60 рабочих дней после подписания итогового акта. п. 5.3. Если Заказчик не подписал акт и не направил мотивированный отказ в течение 5 рабочих дней, работы считаются непринятыми. п. 7.1. За просрочку Исполнитель уплачивает неустойку 1% от цены договора за каждый день просрочки. п. 8.2. Исключительные права на результат работ переходят к Заказчику с момента его создания. п. 10.1. Споры рассматриваются в Арбитражном суде по месту нахождения Заказчика. |
Ответы нейросетей на этот промпт
GigaChat 2 Max06.10.20261. Вывод
Подписывать договор в текущей редакции нельзя — имеются значительные риски нарушения прав исполнителя, необоснованно строгие штрафные санкции и несоразмерная ответственность перед заказчиком. Рекомендуем согласовать изменения хотя бы по ключевым пунктам, представленным ниже.
2. Таблица рисков
| Пункт | Риск | Уровень риска | Предлагаемая редакция |
|---|---|---|---|
| п. 3.4 | Изменение технического задания без пересмотра сроков создаёт серьёзные риски срыва проекта. | Высокий | Дополнить условием: изменение ТЗ возможно только с письменного согласия сторон и корректировкой срока исполнения |
| п. 4.2 | Сроки оплаты длительны и приводят к длительной задержке поступления денежных средств. | Средний | Предложить оплату поэтапно: авансовый платёж 30%, промежуточные платежи по завершении этапов разработки |
| п. 5.3 | Отсутствие обязанности заказчика подписать акт создаёт неоправданные сложности. | Высоко-средний | Уточнить формулировку: если Заказчик не подписал акт и не представил обоснованный отказ в указанный срок, работа считается принятой |
| п. 7.1 | Размер неустойки чрезмерно высок, создавая финансовую угрозу компании-исполнителю. | Высокий | Уменьшить размер пени до разумного уровня (например, 0,1% за день просрочки) |
| п. 8.2 | Переход исключительных прав ранее передачи результата нарушает интересы разработчика. | Средний | Указать, что переход исключительных прав осуществляется одновременно с передачей готового продукта заказчику |
| п. 10.1 | Возможность рассмотрения споров исключительно по месту ответчика ограничивает доступ исполнителя к правосудию. | Средний | Предусмотреть альтернативное место разрешения спора, например по выбору истца либо компромиссное решение |
3. Что не хватает в договоре для защиты нашей стороны?
- Подробное описание порядка сдачи-приемки выполненных работ, критериев качества и формы актов приемки.
- Порядок уведомления сторон друг друга о значимых изменениях и форс-мажорных обстоятельствах.
- Четкое определение процедуры внесения изменений в договор, особенно по техническому заданию.
- Установление гарантийного периода и ответственности заказчика за нарушение условий эксплуатации программы.
- Дополнительные условия ограничения ответственности исполнителя за возможные убытки заказчика.
- Конкретизация случаев освобождения исполнителя от ответственности при нарушении обязательств со стороны заказчика (задержка платежей, отсутствие своевременных инструкций и прочее).
4. Какие вопросы поставить бизнес-заказчику (руководству)?
- Финансовое положение: Каковы реальные возможности компании оплачивать работу вовремя? Есть ли история задержки оплат по другим договорам?
- Опыт сотрудничества: Были ли уже случаи взаимодействия с данным заказчиком? Существуют ли особенности ведения проектов именно с ним?
- Техническая готовность: Насколько проработано текущее техническое задание? Готова ли команда быстро адаптироваться к возможным изменениям требований?
- Ресурсы команды: Хватит ли сотрудников и ресурсов выполнить обязательства даже при изменении объёма работ или ТЗ?
- Уровень контроля: Будут ли привлечены дополнительные специалисты или подрядчики для мониторинга соблюдения графика и бюджета?
Таким образом, важно получить полную картину ситуации, чтобы предложить грамотную стратегию согласования пунктов договора.
ChatGPT (GPT-5.5)06.10.20261. Краткий вывод
Подписывать договор в текущей редакции для Исполнителя не рекомендуется: условия существенно смещают баланс в пользу Заказчика. Наиболее критичные риски — право Заказчика менять ТЗ без изменения сроков, отсутствие автоматической приёмки, высокая неустойка 1% в день и переход прав до оплаты. В текущем виде Исполнитель может выполнить дополнительный объём работ без доплаты, не получить оплату длительное время и при этом нести значительные штрафы. Перед подписанием нужно согласовать изменения как минимум по приёмке, оплате, изменениям ТЗ, ответственности и переходу исключительных прав.
2. Таблица рисков
| Пункт | В чём риск для Исполнителя | Уровень риска | Предлагаемая редакция пункта |
|---|---|---|---|
| п. 3.4. Заказчик вправе в одностороннем порядке изменять техническое задание, сроки выполнения работ при этом не изменяются. | Заказчик может расширять функциональность, менять требования, добавлять работы без изменения цены и сроков. Это создаёт риск бесконечного scope creep: Исполнитель будет обязан выполнять новый объём в прежний срок и за прежнюю цену. Также повышается риск просрочки по причинам, зависящим от Заказчика. | Высокий | Вариант: «Изменение технического задания допускается только по соглашению Сторон путём подписания дополнительного соглашения или согласованной заявки на изменение. В случае изменения ТЗ Стороны согласуют влияние таких изменений на стоимость, сроки, этапы и состав работ. До согласования изменений Исполнитель выполняет работы в соответствии с ранее согласованным ТЗ. Сроки выполнения работ продлеваются на период согласования изменений и на срок, необходимый для их реализации». |
| п. 4.2. Оплата производится в течение 60 рабочих дней после подписания итогового акта. | Оплата только после итоговой сдачи всего проекта и ещё через 60 рабочих дней — это фактически отсрочка примерно на 3 месяца после завершения работ. Исполнитель финансирует проект за свой счёт 5+ месяцев. Нет аванса, этапных платежей, компенсации расходов. Высокий кассовый разрыв. | Высокий | Вариант: «Оплата производится поэтапно: аванс — 30% от цены договора в течение 5 рабочих дней с даты подписания договора; последующие платежи — по итогам выполнения этапов согласно календарному плану; окончательный платёж — 10–20% в течение 5–10 рабочих дней после подписания итогового акта. При просрочке оплаты Заказчик уплачивает неустойку в размере 0,1% от суммы просроченного платежа за каждый день просрочки». |
| п. 5.3. Если Заказчик не подписал акт и не направил мотивированный отказ в течение 5 рабочих дней, работы считаются непринятыми. | Это крайне неблагоприятное условие: молчание Заказчика работает против Исполнителя. Заказчик может не отвечать, и работы будут считаться непринятыми, что блокирует оплату и переход к следующему этапу. Нет механизма автоматической приёмки. | Высокий | Вариант: «Если Заказчик в течение 5 рабочих дней с даты получения акта и результата работ не подписал акт и не направил мотивированный отказ с указанием конкретных недостатков, работы считаются принятыми Заказчиком в полном объёме, а акт — подписанным. Немотивированный отказ от подписания акта не препятствует признанию работ принятыми». |
| п. 7.1. За просрочку Исполнитель уплачивает неустойку 1% от цены договора за каждый день просрочки. | 1% от всей цены договора в день — чрезмерно высокий размер. При цене 3 600 000 ₽ это 36 000 ₽ в день. За месяц просрочки — около 1 080 000 ₽. Не указано ограничение общей ответственности. Неустойка начисляется на всю цену договора, а не на стоимость просроченного этапа. Не учтены задержки со стороны Заказчика. | Высокий | Вариант: «За нарушение срока выполнения соответствующего этапа по вине Исполнителя Исполнитель уплачивает неустойку в размере 0,05% от стоимости просроченного этапа за каждый день просрочки, но не более 5% от стоимости такого этапа. Исполнитель не несёт ответственность за просрочку, возникшую вследствие действий/бездействия Заказчика, включая несвоевременное предоставление информации, материалов, доступов, согласований, обратной связи, а также изменение ТЗ». |
| п. 8.2. Исключительные права на результат работ переходят к Заказчику с момента его создания. | Права переходят до оплаты. Заказчик может получить права на код, дизайн, материалы и использовать результат, даже если не оплатил работы. Также непонятно, что происходит с предшествующими разработками Исполнителя, библиотеками, фреймворками, open-source компонентами, шаблонами, ноу-хау. Есть риск утраты прав на собственные reusable-компоненты. | Высокий | Вариант: «Исключительные права на результаты работ, специально созданные Исполнителем в рамках договора, переходят к Заказчику с даты полной оплаты соответствующих работ/этапа и подписания акта приёмки. До момента полной оплаты Заказчик не вправе использовать результат работ, за исключением тестирования в целях приёмки. Права на предшествующие разработки, программные модули, библиотеки, инструменты, шаблоны, фреймворки, ноу-хау и иные материалы Исполнителя, созданные до заключения договора или независимо от него, Заказчику не отчуждаются; Заказчику предоставляется простая неисключительная лицензия на их использование в составе результата работ в объёме, необходимом для эксплуатации приложения». |
| п. 10.1. Споры рассматриваются в Арбитражном суде по месту нахождения Заказчика. | Если Заказчик находится в другом регионе, Исполнитель понесёт дополнительные расходы на ведение спора. Для Исполнителя это неудобная договорная подсудность. Риск средний, но в сочетании с остальными условиями усиливает переговорную позицию Заказчика. | Средний | Вариант 1: «Споры рассматриваются в Арбитражном суде по месту нахождения ответчика». Вариант 2: «Споры рассматриваются в Арбитражном суде по месту нахождения Исполнителя». Вариант 3: оставить нейтрально по общим правилам процессуального законодательства. |
3. Чего не хватает в договоре для защиты Исполнителя
1. Этапность работ и поэтапная приёмка
Для проекта на 5 месяцев и 3 600 000 ₽ желательно закрепить этапы:
- аналитика / проектирование;
- UX/UI-дизайн;
- разработка backend / frontend / mobile;
- интеграции;
- тестирование;
- публикация / передача результата.
По каждому этапу нужно указать:
- конкретный результат;
- срок;
- стоимость;
- порядок сдачи;
- порядок замечаний;
- последствия непредоставления обратной связи Заказчиком.
Без этапности Исполнитель рискует получить оплату только в конце и спорить по всему проекту целиком.
2. Аванс и график платежей
В договоре нужно предусмотреть:
- аванс до начала работ;
- оплату каждого этапа;
- право приостановить работы при просрочке оплаты;
- неустойку за просрочку оплаты со стороны Заказчика;
- компенсацию дополнительных работ.
Рекомендуемая конструкция:
> «При просрочке оплаты более чем на 5 рабочих дней Исполнитель вправе приостановить выполнение работ до полного погашения задолженности. Сроки выполнения работ продлеваются на период такой приостановки».
3. Порядок внесения изменений в ТЗ
Нужно отдельно закрепить change request procedure:
- кто может инициировать изменение;
- как оформляется заявка;
- как Исполнитель оценивает влияние на сроки и цену;
- что происходит до согласования изменений;
- что считается дополнительными работами.
Важно прямо указать:
> «Любые работы, не предусмотренные ТЗ, выполняются только после согласования Сторонами стоимости и сроков».
4. Обязанности Заказчика
В договоре должны быть обязанности Заказчика:
- предоставить исходные данные;
- предоставить доступы, API, аккаунты, серверы, ключи;
- назначить ответственных лиц;
- своевременно согласовывать результаты;
- предоставлять обратную связь;
- обеспечивать участие своих специалистов;
- соблюдать сроки приёмки;
- не препятствовать выполнению работ.
Также нужно указать, что нарушение этих обязанностей сдвигает сроки Исполнителя.
5. Зависимость сроков Исполнителя от действий Заказчика
Необходимо условие:
> «Сроки выполнения работ продлеваются на период просрочки Заказчиком предоставления информации, материалов, доступов, согласований, обратной связи, оплаты, а также на период устранения препятствий, возникших не по вине Исполнителя».
Это особенно важно для IT-разработки, где результат зависит от данных, интеграций и согласований со стороны Заказчика.
6. Критерии готовности и приёмки результата
В договоре нужно определить:
- что считается надлежащим результатом;
- где и как демонстрируется приложение;
- в какой среде проводится тестирование;
- какие ошибки являются критичными;
- какие ошибки не препятствуют приёмке;
- как фиксируются замечания;
- сроки устранения замечаний;
- количество итераций исправлений.
Желательно ввести классификацию дефектов:
- критические;
- существенные;
- несущественные.
И указать, что несущественные замечания не являются основанием для отказа от приёмки.
7. Ограничение ответственности Исполнителя
Сейчас ответственность не ограничена. Для Исполнителя нужно добавить:
- общий лимит ответственности;
- исключение упущенной выгоды;
- ответственность только за прямой реальный ущерб;
- исключение ответственности за действия третьих лиц, платформ, хостингов, API, App Store / Google Play и т.п.
Пример:
> «Совокупная ответственность Исполнителя по договору ограничивается суммой фактически полученного Исполнителем вознаграждения по соответствующему этапу, но в любом случае не более 20% цены договора. Исполнитель не отвечает за упущенную выгоду, косвенные убытки, потерю данных, простой бизнеса Заказчика, действия третьих лиц, сбои внешних сервисов, маркетплейсов приложений, банковских, платёжных и иных API, если такие обстоятельства не вызваны виновными действиями Исполнителя».
8. Права на предшествующие разработки Исполнителя
Нужно разграничить:
- индивидуально созданный результат для Заказчика;
- стандартные модули Исполнителя;
- библиотеки;
- фреймворки;
- open-source компоненты;
- инструменты разработки;
- внутренние методики и ноу-хау.
Без этого Заказчик может заявить права на то, что Исполнитель использует в других проектах.
9. Условия об open-source и сторонних компонентах
Для мобильного приложения почти наверняка будут использоваться:
- open-source библиотеки;
- SDK;
- API;
- платежные модули;
- аналитика;
- push-сервисы;
- карты;
- авторизация через сторонние сервисы.
Нужно указать:
- что права на сторонние компоненты не передаются;
- Заказчик использует их на условиях правообладателей;
- Исполнитель не отвечает за изменение условий таких сервисов.
10. Гарантийная поддержка и сопровождение
Если Заказчик ожидает поддержку после сдачи, нужно урегулировать:
- есть ли гарантийный период;
- срок гарантийного исправления ошибок;
- какие ошибки исправляются бесплатно;
- что считается доработкой за отдельную плату;
- SLA, если требуется;
- стоимость сопровождения.
Важно исключить из бесплатной гарантии:
- изменение требований;
- новые функции;
- ошибки из-за действий Заказчика;
- изменения внешних API;
- обновления ОС, App Store, Google Play;
- вмешательство третьих лиц в код.
11. Порядок публикации приложения
Если Исполнитель должен публиковать приложение, нужно определить:
- кто предоставляет аккаунты разработчика;
- кто оплачивает аккаунты App Store / Google Play;
- кто является правообладателем аккаунта;
- кто несёт риск отказа модерации;
- входит ли повторная подача в стоимость;
- сроки модерации не зависят от Исполнителя.
Пример:
> «Сроки рассмотрения приложения магазинами приложений не включаются в сроки выполнения работ Исполнителя. Исполнитель не несёт ответственность за отказ в публикации, если он вызван правилами соответствующей платформы, содержанием, материалами или бизнес-моделью Заказчика».
12. Конфиденциальность
Нужно проверить наличие NDA-блока:
- что является конфиденциальной информацией;
- срок охраны;
- исключения;
- ответственность;
- возможность использовать общие знания и навыки;
- право Исполнителя указывать проект в портфолио — если это важно бизнесу.
13. Электронный документооборот и юридически значимые сообщения
Желательно закрепить:
- использование ЭДО;
- допустимость обмена документами по e-mail / мессенджеру / таск-трекеру;
- адреса для уведомлений;
- момент получения сообщений;
- порядок согласования макетов, ТЗ, актов, замечаний.
Для IT-проекта важно, чтобы согласования в Jira, YouTrack, Trello, e-mail или ином трекере имели юридическое значение.
14. Форс-мажор и внешние зависимости
Нужно добавить или проверить положения о:
- сбоях дата-центров;
- блокировках сервисов;
- санкционных ограничениях;
- недоступности сторонних API;
- изменениях правил магазинов приложений;
- ограничениях платёжных систем;
- действиях госорганов.
15. Расторжение договора
Нужно предусмотреть:
- право Исполнителя расторгнуть договор при просрочке оплаты;
- оплату фактически выполненных работ при расторжении;
- порядок передачи результатов;
- судьбу прав на частично оплаченные / неоплаченные результаты;
- компенсацию расходов Исполнителя.
Пример:
> «В случае досрочного прекращения договора Заказчик обязан оплатить фактически выполненные работы и понесённые Исполнителем расходы. Исключительные права на неоплаченные результаты работ Заказчику не переходят».
4. Вопросы к бизнесу перед переговорами
По коммерческим условиям
- Готовы ли мы работать без аванса или минимально нужен аванс? Если да, какой размер: 30%, 40%, 50%?
- Допустим ли для нас платёж только после итоговой сдачи проекта?
- Какой максимальный срок отсрочки оплаты приемлем: 5, 10, 15 рабочих дней?
- Нужна ли поэтапная оплата? Какой календарный план удобен для команды?
- Есть ли у нас внутренний лимит по кассовому разрыву на этот проект?
По срокам и объёму работ
- Насколько детализировано техническое задание уже сейчас?
- Есть ли риск, что ТЗ будет меняться в процессе?
- Какие функции являются базовыми, а какие могут стать дополнительными работами?
- Заложен ли буфер на изменения требований Заказчика?
- Реален ли срок 5 месяцев при текущем объёме работ?
- Какие зависимости от Заказчика критичны для соблюдения сроков: доступы, API, контент, дизайн, согласования, тестовые данные?
По команде и ресурсам
- Сколько специалистов будет занято на проекте?
- Есть ли риск, что из-за задержки оплаты или согласований команда будет простаивать?
- Можем ли мы выделить команду на 5 месяцев без этапных платежей?
- Есть ли параллельные проекты, которые могут повлиять на сроки?
По приёмке
- Кто со стороны Заказчика будет принимать результат?
- Нужна ли нам поэтапная приёмка?
- Какой срок приёмки для нас приемлем: 5, 7, 10 рабочих дней?
- Какие замечания должны считаться существенными?
- Готовы ли мы принять правило: если Заказчик молчит, работы считаются принятыми?
По ответственности
- Какой максимальный размер неустойки для нас приемлем?
- Готовы ли мы согласиться на неустойку от всей цены договора или только от стоимости этапа?
- Какой общий лимит ответственности нужно поставить: 10%, 20%, 30% от цены договора?
- Были ли в похожих проектах риски просрочки из-за действий заказчика?
- Есть ли риск, что Заказчик будет использовать штрафы как инструмент давления?
По интеллектуальным правам
- Используем ли мы свои готовые модули, библиотеки, шаблоны, фреймворки?
- Есть ли компоненты, которые мы используем в других проектах и не готовы отчуждать?
- Будет ли использоваться open-source?
- Есть ли сторонние SDK, API, платёжные системы, карты, аналитика, push-сервисы?
- Готовы ли мы передавать исключительные права только после полной оплаты?
- Нужно ли сохранить право использовать общие идеи, подходы, опыт и наработки в других проектах?
По поддержке и эксплуатации
- Входит ли поддержка после запуска в цену 3 600 000 ₽?
- Если входит, то на какой срок и в каком объёме?
- Кто будет размещать приложение в App Store / Google Play?
- Кто предоставляет аккаунты разработчика?
- Кто несёт риск отказа модерации?
- Нужен ли отдельный договор или допсоглашение на сопровождение?
По переговорам
- Какие условия для нас являются «красными линиями»?
- На какие уступки мы готовы пойти?
- Что важнее сохранить: аванс, сроки, лимит ответственности, переход прав после оплаты, автоматическую приёмку?
- Есть ли у Заказчика сильная переговорная позиция или можно настаивать на наших правках?
- Готовы ли мы отказаться от сделки, если Заказчик не согласует ключевые изменения?
Claude Sonnet 506.10.2026Юридический анализ договора на разработку мобильного приложения (позиция исполнителя)
1. Краткий вывод
В текущей редакции договор подписывать нельзя — он системно выстроен в пользу заказчика и содержит как минимум два пункта (3.4 и 5.3), которые в совокупности создают риск бесконечного и бесплатного выполнения работ без оплаты. Отсрочка платежа 60 рабочих дней при фиксированной цене создаёт серьёзный кассовый разрыв на проекте с 5-месячным циклом. Неустойка 1%/день несоразмерна и требует снижения. Требуется содержательная правка минимум 5 пунктов и добавление отсутствующих механизмов защиты (поэтапная оплата, регламент приёмки, ограничение ответственности).
2. Таблица рисков
| Пункт | Риск для исполнителя | Уровень | Предлагаемая редакция |
|---|---|---|---|
| 3.4 | Заказчик может бесконечно расширять объём работ («scope creep»), не меняя срок и, по умолчанию, цену — классический риск бесплатного объёма | Высокий | «Заказчик вправе инициировать изменение ТЗ. Изменения согласовываются сторонами путём подписания дополнительного соглашения с указанием влияния на срок и цену договора. Без подписания такого соглашения Исполнитель не обязан выполнять измененные требования» |
| 4.2 | Отсрочка оплаты ~3 календарных месяца после сдачи — кассовый разрыв, риск неполучения оплаты при проблемах у заказчика | Высокий | «Оплата производится в течение 10 рабочих дней после подписания акта. Не менее 30% цены договора уплачивается авансом, оставшаяся часть — поэтапно по актам сдачи-приёмки этапов» |
| 5.3 | Инверсия стандартной логики: молчание заказчика = работы НЕ приняты (а не приняты, как обычно). Исполнитель лишён возможности зафиксировать приёмку в одностороннем порядке | Высокий | «Если Заказчик в течение 5 рабочих дней не подписал акт и не направил мотивированный письменный отказ с перечнем конкретных замечаний со ссылкой на ТЗ, работы считаются принятыми, а акт — подписанным» |
| 7.1 | 1% в день = 365% годовых, несоразмерная неустойка; не указано, от какой суммы (от цены всего договора, а не невыполненного этапа) | Высокий | «Неустойка — 0,1% от стоимости не выполненного в срок этапа за каждый день просрочки, но не более 10% от стоимости соответствующего этапа» |
| 8.2 | Права переходят до полной оплаты — Исполнитель теряет рычаг давления в случае неоплаты; также неясно про компоненты, созданные до проекта (библиотеки, фреймворки) | Средний/Высокий | «Исключительные права на результат работ переходят к Заказчику в объёме и с момента полной оплаты по договору. Исполнитель сохраняет права на ранее созданные компоненты, библиотеки, ноу-хау и предоставляет Заказчику неисключительную лицензию на их использование в составе результата работ» |
| 10.1 | Неудобная для исполнителя подсудность (логистика, затраты на участие в процессе) | Низкий/Средний | «Споры рассматриваются в Арбитражном суде по месту нахождения Исполнителя» либо нейтральная подсудность/третейская оговорка |
3. Чего не хватает в договоре
- Поэтапная структура оплаты и приёмки — сейчас похоже на один итоговый акт в конце 5 месяцев, что максимизирует риск исполнителя.
- Регламент приёмки: критерии соответствия ТЗ, порядок тестирования, формат и сроки устранения замечаний, количество итераций.
- Встречные обязательства заказчика и ответственность за их неисполнение: предоставление контента, доступов, API-ключей, тестовых стендов, согласование макетов в срок — с указанием, что просрочка заказчика сдвигает сроки исполнителя автоматически.
- Ограничение (cap) общей ответственности исполнителя — например, не более цены договора/этапа.
- Форс-мажор.
- Гарантийный период после сдачи (багфиксинг) — отдельно от основного объёма, с указанием, что не входит в срок проекта.
- Условия и порядок расторжения договора, в т.ч. оплата фактически выполненного объёма при одностороннем отказе заказчика.
- Конфиденциальность/NDA (если отсутствует отдельное соглашение).
- Порядок передачи исходного кода/материалов и момент его осуществления (целесообразно — после оплаты).
- Указание, что сроки выполнения работ продлеваются пропорционально при изменении ТЗ по п. 3.4 (взаимосвязано с правкой этого пункта).
4. Вопросы к бизнесу перед переговорами
- Готовы ли мы финансово работать 5 месяцев без аванса и с отсрочкой оплаты ещё на 2-3 месяца после сдачи (расчёт кассового разрыва)?
- Цена 3 600 000 ₽ фиксированная за весь объём ТЗ — или мы закладывали буфер на доработки/правки заказчика? Какой процент буфера приемлем для нас, если заказчик не согласится убрать п. 3.4 полностью?
- Есть ли у нас референсы/история работы с этим заказчиком? Известна ли его платёжная дисциплина и репутация в части приёмки работ?
- Критично ли для нас сохранить права на свои наработки (внутренние библиотеки, фреймворк, no-code/low-code решения), которые будем переиспользовать в других проектах?
- Насколько мы готовы идти на уступки по неустойке (п. 7.1) и подсудности (п. 10.1) — есть ли у нас "красные линии" для этой сделки?
- Предусмотрена ли в бюджете проекта отдельная оценка гарантийного/постпроектного сопровождения (багфиксинг), или это должно быть включено в цену 3 600 000 ₽?
- Какие есть дедлайны у заказчика на подписание договора — есть ли пространство для переговоров по срокам, или нас торопят, чтобы продавить невыгодные условия?
Gemini 2.5 Flash06.10.2026Анализ договора на разработку мобильного приложения (позиция Исполнителя)
1. Краткий вывод
В текущей редакции договор категорически не рекомендуется к подписанию. Он содержит ряд критических рисков для Исполнителя, которые могут привести к значительным финансовым потерям, затягиванию проекта и невозможности получить оплату. Необходима существенная доработка ключевых пунктов для обеспечения баланса интересов сторон.
2. Таблица рисков
| Пункт договора | В чём риск для нас (Исполнителя) | Уровень риска | Предлагаемая редакция пункта |
|---|---|---|---|
| п. 3.4. Заказчик вправе в одностороннем порядке изменять техническое задание, сроки выполнения работ при этом не изменяются. | Высокий. Заказчик может бесконечно менять ТЗ, увеличивая объем работ, но при этом сроки и, вероятно, цена останутся прежними. Это прямой путь к переработкам, срыву сроков по вине Заказчика и отсутствию дополнительной оплаты. | Высокий | "3.4. Заказчик вправе вносить изменения в Техническое задание. В случае, если такие изменения влекут за собой увеличение объема работ, изменение сроков выполнения работ или увеличение стоимости работ, Стороны обязуются согласовать новые сроки и/или стоимость работ путем подписания дополнительного соглашения. До момента подписания дополнительного соглашения Исполнитель продолжает выполнение работ в соответствии с ранее утвержденным Техническим заданием." |
| п. 4.2. Оплата производится в течение 60 рабочих дней после подписания итогового акта. | Высокий. Чрезмерно длительный срок оплаты. 60 рабочих дней (это около 3 месяцев) после завершения всех работ создает значительный кассовый разрыв и финансовую нагрузку на Исполнителя. | Высокий | "4.2. Оплата производится в течение 10 (десяти) рабочих дней после подписания итогового акта. Предусмотреть авансовые платежи или поэтапную оплату." |
| п. 5.3. Если Заказчик не подписал акт и не направил мотивированный отказ в течение 5 рабочих дней, работы считаются непринятыми. | Высокий. Это крайне невыгодная формулировка. Обычно, если Заказчик молчит, работы считаются принятыми. Здесь же молчание означает непринятие, что позволяет Заказчику бесконечно затягивать приемку и оплату без объяснения причин. | Высокий | "5.3. Если Заказчик не подписал акт выполненных работ и не направил мотивированный отказ в течение 5 (пяти) рабочих дней с даты его получения, работы считаются принятыми Заказчиком в полном объеме, и акт считается подписанным." |
| п. 7.1. За просрочку Исполнитель уплачивает неустойку 1% от цены договора за каждый день просрочки. | Высокий. Неустойка в 1% от цены договора (3 600 000 ₽) за каждый день просрочки – это 36 000 ₽ в день. Это чрезмерно высокая и кабальная неустойка, которая может привести к тому, что сумма неустойки превысит стоимость договора за относительно короткий срок. | Высокий | "7.1. За просрочку выполнения работ Исполнитель уплачивает Заказчику неустойку в размере 0,1% от стоимости невыполненных в срок работ за каждый день просрочки, но не более 10% от общей цены договора." |
| п. 8.2. Исключительные права на результат работ переходят к Заказчику с момента его создания. | Средний. Риск заключается в том, что Исполнитель не имеет гарантии оплаты до момента перехода прав. В случае спора об оплате, Заказчик уже обладает правами на результат работ, что снижает рычаги воздействия Исполнителя. | Средний | "8.2. Исключительные права на результат работ переходят к Заказчику в полном объеме с момента полной оплаты Заказчиком выполненных работ по Договору." |
| п. 10.1. Споры рассматриваются в Арбитражном суде по месту нахождения Заказчика. | Средний. Это неудобно и затратно для Исполнителя, если Заказчик находится в другом регионе. | Средний | "10.1. Споры рассматриваются в Арбитражном суде по месту нахождения Исполнителя." или "10.1. Споры рассматриваются в Арбитражном суде по месту нахождения ответчика." (более нейтральный вариант). |
3. Чего не хватает в договоре для защиты нашей стороны
- Поэтапная оплата и/или аванс: Отсутствие аванса и поэтапной оплаты при длительном сроке проекта (5 месяцев) и отсрочке платежа в 60 рабочих дней создает огромный кассовый разрыв и финансовую нагрузку на Исполнителя.
- Порядок приемки-передачи работ по этапам: Договор упоминает только "итоговый акт". Для такого длительного проекта критически важна поэтапная приемка с подписанием промежуточных актов, что позволит фиксировать выполненный объем и получать оплату частями.
- Порядок изменения ТЗ и его влияние на сроки/стоимость: Пункт 3.4. требует кардинальной доработки. Необходимо четко прописать процедуру согласования изменений, их влияние на сроки и стоимость, а также порядок оформления (дополнительное соглашение).
- Ограничение ответственности Исполнителя: Отсутствует пункт, ограничивающий ответственность Исполнителя (например, по косвенным убыткам, упущенной выгоде Заказчика) или устанавливающий верхний предел ответственности (например, суммой договора).
- Порядок взаимодействия сторон: Не хватает четких правил коммуникации, сроков ответов на запросы, предоставления информации Заказчиком, что может влиять на сроки выполнения работ.
- Форс-мажор: Стандартный пункт о форс-мажоре, который освобождает стороны от ответственности за неисполнение обязательств при наступлении определенных обстоятельств.
- Гарантийные обязательства Исполнителя: Необходимо четко прописать объем и срок гарантийных обязательств на разработанное приложение, а также порядок устранения выявленных дефектов.
- Конфиденциальность: Если предполагается обмен конфиденциальной информацией, необходим соответствующий раздел.
- Порядок расторжения договора: Должны быть прописаны условия и последствия расторжения договора по инициативе любой из сторон.
- Ответственность Заказчика: Отсутствует ответственность Заказчика за несвоевременное предоставление информации, материалов, задержку приемки или оплаты. Это создает дисбаланс.
4. Вопросы к бизнесу (заказчику сделки), которые нужно задать до переговоров
- Порядок оплаты: Готов ли Заказчик рассмотреть поэтапную оплату или авансовый платеж? Какой максимальный срок отсрочки платежа после подписания акта для них приемлем?
- Изменение ТЗ: Какова их практика работы с изменениями в ТЗ на других проектах? Готовы ли они к тому, что изменения, влияющие на объем/сроки/стоимость, будут оформляться дополнительными соглашениями?
- Приемка работ: Почему в договоре предусмотрено, что молчание Заказчика означает непринятие работ (п. 5.3.)? Готовы ли они изменить этот пункт на стандартную формулировку, где молчание означает принятие?
- Неустойка: Насколько критична для них такая высокая неустойка (1% в день)? Готовы ли они к ее снижению до разумных пределов, соответствующих рыночной практике?
- Переход прав: Почему исключительные права должны переходить с момента создания, а не с момента полной оплаты? Готовы ли они к изменению этого пункта?
- Судебная юрисдикция: Насколько принципиален Арбитражный суд по месту их нахождения? Готовы ли они рассмотреть вариант по месту нахождения ответчика или Исполнителя?
- Поэтапная приемка: Планируется ли поэтапная приемка работ по мере их выполнения? Если да, то как они видят этот процесс и оформление?
- Ответственность Заказчика: Какие санкции они готовы предусмотреть для себя в случае задержки с предоставлением информации/материалов или задержки оплаты?
- Бюджетные ограничения: Есть ли у них жесткие бюджетные ограничения, которые не позволяют увеличить стоимость договора при изменении ТЗ?
- Причины такой редакции: Были ли у них негативные опыты с другими исполнителями, которые привели к такой жесткой редакции договора? Понимание их мотивов может помочь в переговорах.
Советы
- Вставляйте договор целиком, если он не слишком длинный: опасные условия часто прячутся в определениях и приложениях.
- Названия сторон, ИНН и реквизиты замените условными: для анализа рисков они не нужны.
Как пользоваться
- Скопируйте промпт кнопкой выше.
- Замените поля в фигурных скобках своими данными.
- Отправьте в нейросеть и сравните ответ с примером на этой странице.
Подробнее о структуре хорошего запроса: гид AI University.
Похожие промпты
ЮристуБесплатно
Досудебная претензия о взыскании долгаПретензия контрагенту о погашении долга и неустойки перед обращением в арбитражный суд.
4 ответаОткрытьЮристуБесплатно
Исковое заявление в арбитражный судЧерновик иска о взыскании долга и неустойки со структурой, приложениями и слабыми местами позиции.
4 ответаОткрытьЮристуС доступом
Протокол разногласий к договоруТаблица разногласий с редакцией контрагента, вашей редакцией и обоснованием для переговоров.
4 ответаСмотреть ответы
4 ответаОткрытьЮристуБесплатно
Исковое заявление в арбитражный судЧерновик иска о взыскании долга и неустойки со структурой, приложениями и слабыми местами позиции.
4 ответаОткрытьЮристуС доступом
Протокол разногласий к договоруТаблица разногласий с редакцией контрагента, вашей редакцией и обоснованием для переговоров.
4 ответаСмотреть ответыВсе 435 промптов и 6 наборов
172 промптов открыты бесплатно. Остальные и наборы-цепочки открывает доступ к библиотеке за 1 490 ₽. Полный доступ за 4 900 ₽: все курсы AI University на русском и библиотека промптов. Разовый платёж, новые промпты входят.