Разработчик сорвал IT‑проект? Решим спор и доведём проект до рабочего результата
Один вход — два результата. Юрист разбирает договор, ТЗ, оплату, права и требования к подрядчику. Техническая команда фиксирует код и инфраструктуру, определяет, что можно сохранить, и при необходимости сама принимает проект в работу: восстанавливает контроль, исправляет, доделывает или пересобирает проблемную часть. Вам не нужно отдельно искать юриста и нового разработчика.
Не отправляем вас от юриста к программисту: закрываем юридическую и техническую часть в одной команде
Обычный IT‑юрист может подготовить претензию, но не завершит систему. Обычный разработчик может исправлять код, но его вмешательство способно уничтожить доказательства и ухудшить позицию в споре. Мы сначала согласуем обе части, а затем действуем по одному плану.
Юридический контур
Договор, ТЗ, сроки, акты, переписка, права, претензия, переговоры и при необходимости судебная стратегия.
Технический контур
Git, сервер, БД, API, логи, тестирование, восстановление доступов, оценка пригодного кода и план безопасного продолжения.
Доведение до результата
Если проект целесообразно спасать, после фиксации и получения необходимых прав/доступов можем сами взять его на доработку. Если дешевле пересобрать — спроектируем замену, сохранив доказательства по старому проекту.
Не меняйте спорную версию проекта, пока её не зафиксировали
После вмешательства нового программиста старый подрядчик может заявить, что ошибки появились уже после его работы. Поэтому сначала создаём доказуемый «снимок», потом ремонтируем.
Сделайте копию до любых исправлений. Репозиторий с историей коммитов, архив файлов production, дамп базы, логи, конфигурацию, видео ключевых сценариев и список доступов. Если доступа к части инфраструктуры нет — отдельно фиксируем сам факт отсутствия доступа.
- договор, приложения, спецификации и ТЗ;
- переписка о сроках, изменениях и согласовании этапов;
- платежи, счета, акты и мотивированные замечания;
- GitHub/GitLab/Bitbucket или архивы исходников;
- сервер, облако, домен, DNS, сертификаты;
- база данных и миграции;
- API‑ключи, вебхуки и внешние интеграции;
- список функций, которые отсутствуют или воспроизводимо ломаются.
Как выглядит IT‑конфликт в цифрах и документах
Примеры ниже смоделированы на основе типичных условий IT‑договоров и судебных споров. Это не истории конкретных клиентов ПравДок и не обещание аналогичного результата.
Оплачено 360 000 ₽ из 480 000 ₽, срок прошёл, ключевые функции отсутствуют
По ТЗ бот должен авторизовать клиента, создавать заявку в CRM, принимать оплату, показывать статус, отправлять документы и иметь административный контур. Фактически работают авторизация, анкета и уведомления; CRM создаёт дубли, платежи отсутствуют, административная часть не реализована. Подрядчик требует ещё 120 000 ₽ и обещает завершить «после доплаты».
Что фиксируем
- текущий commit и рабочую сборку;
- 19 требований ТЗ поштучно;
- логи ошибок CRM;
- отсутствие платёжного сценария;
- переписку о сроках и доплате.
Что не делаем
- не объявляем автоматически «готовность 57,9%» денежной стоимостью;
- не меняем код до копии;
- не обещаем вернуть все 360 000 ₽ без анализа полезного результата.
Работает 70%, новый программист предлагает переписать всё
Типовая ситуация: CRM‑интеграция и база нормальные, а интерфейс и авторизация нестабильны. Технический аудит показывает, что сохраняются backend, БД и часть API. Переписывание 100% проекта увеличило бы стоимость и разрушило бы доказательства. Решение — зафиксировать спорную версию, выделить пригодные компоненты и менять только проблемный слой.
Акт подписан, но через неделю всплыла критическая ошибка
Типовая ситуация: внешне кабинет открывался, но при реальной нагрузке платежи дважды создавали заказы. Проверяем процедуру приёмки, гарантию, характер дефекта, мог ли он быть обнаружен обычной проверкой и кто менял production после сдачи. Подписанный акт важен, но сам по себе не заменяет анализ обстоятельств.
Бот работает, но всё находится на аккаунтах подрядчика
Код в его GitHub, сервер на его облаке, домен и API‑ключи оформлены на его учётные записи. Даже работающий продукт остаётся операционно зависимым. Составляем реестр цифровых активов и отдельно проверяем, какие обязанности по передаче и права предусмотрены договором.
Заказчик тоже задерживал проект
Исполнитель просил API, тексты и доступ к 1С, а заказчик передал их через месяц. Это влияет на оценку просрочки и ответственности. Сильная стратегия не прячет неудобные факты: восстанавливаем хронологию и отделяем задержку подрядчика от встречного неисполнения заказчика.
Юрист проверяет обязательство, технический специалист — реальный результат
Фраза «сайт плохой» не является техническим доказательством, а наличие ZIP‑архива ещё не означает передачу работоспособного продукта.
| Слой | Юридическая проверка | Техническая проверка | Итог |
|---|---|---|---|
| Предмет | Договор, ТЗ, приложения, изменения | Функции и компоненты, существующие в проекте | Матрица «обещано / сделано / спорно» |
| Срок | Этапы, переносы, уведомления, встречные обязанности | Коммиты, релизы, даты deployment | Хронология исполнения |
| Качество | Приёмка, гарантия, критерии результата | Тесты, логи, API, производительность, воспроизводимость | Перечень подтверждённых дефектов |
| Передача | Что исполнитель обязан предоставить | Git, БД, сервер, домен, ключи, CI/CD, документация | Реестр недостающих цифровых активов |
| Права | Условия об исключительных правах и лицензиях | Состав собственного и стороннего кода | Что можно продолжать использовать и изменять |
| Экономика | Оплата, этапы, ответственность | Что технически пригодно для продолжения | Сравнение «спасать / переписывать / взыскивать» |
Фиксируем версию проекта и доказательства так, чтобы новый ремонт не уничтожил картину старого исполнения.
Восстанавливаем, что именно было согласовано и как менялось ТЗ.
Проверяем существенные сценарии по принципу «требование → тест → результат → доказательство».
Сопоставляем юридический риск, стоимость незавершённого объёма и цену rescue‑разработки.
Претензия, требование передачи, переговоры или иск — и, если принято решение сменить подрядчика, техническое продолжение проекта нашей командой после безопасной фиксации.
Какие нормы обычно приходится сопоставлять
IT‑договор может называться «услугами», но предусматривать создание конкретного результата. Квалификация зависит от содержания договора, поэтому нельзя механически применять одну статью ко всем проектам.
Ст. 715 ГК РФ. Имеет значение при нарушении темпа и срока выполнения подрядных работ, когда своевременное завершение становится явно невозможным.
Ст. 720, 723, 724 ГК РФ. Приёмка, последствия недостатков и сроки их обнаружения. Эти нормы особенно важны, если акт уже подписан.
Ст. 1296 ГК РФ. Специальные правила для программ для ЭВМ и баз данных, созданных по заказу. Условия конкретного договора о правах всё равно проверяются отдельно.
Мы не подгоняем факты под заранее выбранное требование. Сначала устанавливаем предмет договора и фактическое исполнение. Иногда выгоднее взыскание, иногда — передача исходников, а иногда разумнее сохранить работающую часть и закончить проект. В последнем случае клиент может не искать ещё одного подрядчика: техническую доработку можем выполнить мы сами.
Почему техническая проверка меняет исход IT‑спора
Ниже — не «наши победы», а публичные судебные дела, показывающие разные сценарии.
А76‑30772/2025 — чат‑бот не дал заказчику пригодного результата
Суд исследовал ТЗ, интеграции, запуск переданного кода и переписку. В материалах фигурировал аванс 720 000 ₽; заказчик оспаривал наличие готового продукта, а суд отметил конкретный результат как цель отношений. Постановление 18 ААС от 19.12.2025.
А62‑5256/2024 — заказчик требовал возврат, но экспертиза подтвердила выполнение
ТЗ восстанавливали в том числе по переписке Telegram. Эксперт признал результат соответствующим договору и заданию, а существенная часть претензий заказчика не привела к возврату оплаты. Постановление 20 ААС от 02.07.2026. Это важный контрпример: спор надо проверять до обещаний клиенту.
А60‑65155/2024 — часть претензий относилась к программированию, которого не было в предмете договора
Судебная экспертиза отделила работы по прототипу, дизайну и вёрстке от программирования; учитывались подписанные акты, сроки обнаружения недостатков и доступ третьих лиц к сайту. Постановление 17 ААС от 07.05.2026.
А45‑26234/2022 — права на программу и фактическая передача исходников
Суды отдельно исследовали GitHub‑репозитории, доступ к исходному коду и доказательства его передачи. Скриншотов переписки оказалось недостаточно, чтобы подтвердить передачу конкретного кода. Постановление СИП от 18.07.2023.
Четыре результата, к которым может привести разбор
Забрать
Получить предусмотренные договором исходники, репозиторий, БД, серверные доступы, домен, ключи и документацию.
Вернуть
При наличии оснований определить денежное требование с учётом фактически созданного и принятого результата.
Доделать
Сохранить пригодный код и после фиксации спорной версии принять проект в техническую работу: устранить критические дефекты и реализовать недостающие функции.
Пересобрать
Если спасать старый код экономически неразумно — сохранить доказательства и данные, затем спроектировать и реализовать новую версию без зависимости от прежнего подрядчика.
| Что получает заказчик после первичного разбора | Практический смысл |
|---|---|
| Реестр документов и цифровых активов | Понимание, что находится у заказчика, а что осталось у подрядчика. |
| Матрица существенных требований ТЗ | Не общая оценка, а проверяемые пункты исполнения. |
| Перечень доказательств и пробелов | Что уже можно использовать и что нужно получить до претензии/иска. |
| Правовая стратегия | Какие требования имеют фактическое и договорное основание. |
| Технический rescue‑план и реализация | Что сохраняем, что исправляем или переписываем, какие доступы критичны и можем ли мы сами довести проект до рабочего состояния. |
Отдельные материалы по конкретной проблеме
Разработчик не доделал проект
Срок, объём, частичное исполнение и выбор требования.
Не передают исходники и доступы
Git, сервер, домен, БД, права и фактическая передача.
Как вернуть деньги за разработку
Почему возврат не равен автоматически всей сумме платежей.
Технический аудит для спора
Как зафиксировать версию, дефекты и соответствие ТЗ.
Частые вопросы
Можно ли обратиться, если договора нет, а есть только переписка и платежи?
Да, но сначала нужно установить, что именно было согласовано и можно ли доказать объём обязательств. В IT‑спорах переписка, счета, переданные макеты, доступы и фактические действия сторон могут иметь существенное значение.
Акт подписан. Есть ли смысл что-то проверять?
Есть. Но подписанный акт существенно влияет на позицию. Проверяются условия приёмки, гарантия, характер дефекта, момент его обнаружения и изменения проекта после сдачи.
Вы сами можете доделать проект после спора со старым разработчиком?
Да, если после аудита это технически и экономически разумно и у заказчика есть необходимые права и доступы. Сначала фиксируем спорную версию и доказательства, затем наша техническая команда может принять проект на стабилизацию, доработку или частичную пересборку.
Вы обязательно предлагаете суд?
Нет. Цель — экономически разумное завершение конфликта. Иногда переговоры и передача проекта выгоднее многомесячного процесса.
Можно ли взыскать стоимость переписывания проекта новым разработчиком?
Это зависит от договора, причин необходимости новой разработки, доказанности убытков и причинной связи. Само наличие коммерческого предложения нового исполнителя ещё не гарантирует взыскание этой суммы.
Что прислать для первого разбора?
Договор и ТЗ, платежи, акты, ключевую переписку, ссылку на работающий результат и краткий список того, что должно было работать, но не работает или отсутствует.
Один запрос — разберём спор и техническое продолжение проекта
Опишите, что заказывали, сколько оплатили, какой был срок и что получили фактически. Мы оценим не только требования к старому подрядчику, но и можно ли сохранить существующий код и принять проект на доработку. Если проект ещё доступен — не меняйте старую версию до резервной копии и фиксации.
Первичный вывод не заменяет изучение договора и материалов. Мы не обещаем взыскание или возврат до проверки фактов.
Опишите вопрос — юрист разберётся
Напишите, что произошло, когда узнали и какой результат нужен. Остальное уточнит специалист.