Компания заказала разработку платформы пропускной системы, мобильное приложение и сервис. Заплатила 2 696 000 рублей. Получила исходники, зарегистрировала программу в Роспатенте через аффилированное юрлицо, опубликовала приложение на RuMarket и в AppStore. А потом направила разработчику уведомление об отказе от договора и потребовала вернуть все деньги как неосновательное обогащение, якобы работы выполнены не были.
Дело дошло до двух судебных экспертиз, апелляции и кассации. Разработчик выиграл. Ниже подробно опишем то, что стало ключевым и привело его к победе.
Как это стало возможным
Такие дела начинаются одинаково. Разработчик сдал работу, заказчик её получил, какое-то время всё шло в штатном режиме - переписка, правки, уточнения. А потом что-то пошло не так. То ли ожидания разошлись с реальностью, то ли бюджет закончился раньше, то ли просто пришло понимание, что можно попробовать не платить. Дальше заказчик перестаёт выходить на связь, акты не подписывает, а через какое-то время присылает уведомление об отказе от договора с требованием вернуть всё до копейки.
Логика иска в таких случаях проста и внешне выглядит убедительно. Двусторонних актов нет, значит, работы формально не приняты. Раз не приняты, значит, деньги удерживаются без оснований, то есть неосновательное обогащение. Дальше суд, и разработчику предлагают доказать, что работа вообще была и результат он передал.
Именно здесь многие проигрывают, не потому что ничего не делали, а потому что делали, но не оставили следов, которые можно было бы положить в основу позиции. Нет приказа о начале работ, нет переписки с чёткой привязкой к этапам, нет фиксации передачи исходников - и тогда даже очевидная для всех участников история превращается в слово против слова.
В деле № А45-16475/2023, которое рассматривал Арбитражный суд Новосибирской области, всё могло пойти по тому же сценарию. Но не пошло. Наша фирма представляла интересы разработчика, и то, что в итоге определило исход, это не какие-то специально подготовленные к суду документы, а обычные цифровые следы ведения проекта: переписка, история репозитория, действия самого заказчика. Разбираем, как именно это сложилось в выигрышную позицию.
Что заказчик сделал с продуктом, пока говорил, что его нет
Пока стороны обменивались претензиями и разработчик ждал подписанных актов, на другом конце происходило кое-что интересное. Аффилированная с заказчиком компания (с тем же директором и единственным участником) подала заявку в Роспатент на регистрацию программы для ЭВМ. То есть пока шли разговоры о том, что работы якобы не выполнены, заказчик через связанное юрлицо оформлял права на результат этих работ.
Но это ещё не всё. Для регистрации программы в Роспатенте нужен исходный код - его не возьмёшь из воздуха. За несколько недель до подачи заявки сотрудник разработчика направила заказчику письмо с исходным кодом на 300 листов - специально для регистрации. Адвокат осмотрел эту переписку и зафиксировал её содержание в протоколе. Письмо оказалось в деле.
Параллельно разворачивалась ещё одна история. Мобильное приложение появилось на RuMarket, затем в AppStore. В январе 2023 года представитель заказчика написала разработчику короткое сообщение: «Приложения работают, спасибо».
А чуть позже заказчик направил уведомление об отказе от договора с требованием вернуть 2 696 000 рублей, якобы работы выполнены не были.
Суд смотрел на всё это в совокупности и пришёл к очевидному выводу. Заказчик, который получил исходный код, зарегистрировал на его основе программу в Роспатенте, опубликовал приложение в маркетплейсах и написал "спасибо, работает" – явно указывает на приемку результата. Факт использования продукта суд квалифицировал как фактическую приёмку, и последующее уведомление об отказе этого не отменяло.
Почему односторонние акты были не лишними
Разработчик направил акты выполненных работ, заказчик их не подписал - просто проигнорировал. И здесь многие разработчики делают одну и ту же ошибку, решают, что раз подписи нет, то и доказательств нет, и начинают нервно ждать развития событий.
На самом деле неподписанный акт - это не тупик, если понимать, как суды оценивают сдачу результата и доказательства выполнения работ. Логика там следующая. Заказчик имеет право отказаться от приёмки результата, но этот отказ должен быть мотивированным и письменным с указанием конкретных недостатков, которые мешают использовать результат. Просто промолчать недостаточно. Молчание в данном случае работает против заказчика, а не против разработчика.
Заказчик в этом деле мотивированного отказа так и не направил. Никакого письма с перечнем претензий к конкретным функциям, никакого документа с описанием того, что именно не работает и почему это исключает использование продукта. Была общая риторика о том, что работы не выполнены, но не было того, что суд мог бы счесть обоснованным отказом от приёмки. Все это в совокупности с другими доказательствами разбивало легенду заказчика о том, что он ничего не получил и результат не достигнут.
Как помог GitLab
Когда основная экспертиза уже была проведена, в деле возник отдельный вопрос, который потребовал дополнительного исследования. Заказчик передал разработчику USB-накопитель с файлами, но когда именно эти файлы были созданы? Можно ли установить, что переданная версия ПО действительно соответствует тому периоду работы, о котором говорит разработчик?
Суд назначил дополнительную экспертизу. Эксперты взяли файлы с накопителя и сопоставили их с историей репозиториев в GitLab. То, что они увидели, не оставило вопросов. Метаданные исходного кода показали, что версия программного обеспечения сформирована в период работы по договору. Признаков изменения дат создания файлов не обнаружено.
GitLab в этой ситуации сработал как объективный регистратор событий. История коммитов с временными метками, авторы изменений, ветки - всё это данные, которые сложно незаметно переписать задним числом. Именно поэтому эксперты, а потом и суд опирались на них без колебаний.
Две экспертизы и что они установили
Заказчик продолжал настаивать на своём - работы не выполнены, деньги надо вернуть. Суд назначил экспертизу, и здесь начался, пожалуй, самый долгий этап всего разбирательства.
Первая экспертиза разбиралась с основным объёмом работ по договору. Эксперты изучили платформу, мобильное приложение, сервис, и зафиксировали, что работы выполнены на 91,55%, соответствуют качеству и пригодны к использованию по назначению. Единственное, чего не хватало, это поддержки BLE-маяков и устойчивой работы при нестабильном интернете. Суд квалифицировал это как несущественные недостатки. Продукт работал, использоваться мог, а значит, оснований для отказа в приёмке не было.
Заказчик попытался опровергнуть выводы экспертов через рецензию стороннего специалиста. Рецензия критиковала методологию, указывала на погрешности, но суд её отклонил. Суд не принял рецензию как достаточное опровержение экспертизы. Такие документы, представленные по инициативе стороны, часто оцениваются судами критически.
Дополнительная экспертиза занималась работами сверх основного договора. Эксперты не просто подтвердили факт выполнения, но и установили реальную стоимость этих работ. Все модули функциональны, интегрированы в платформу, критических дефектов нет.
Что в итоге
Арбитражный суд Новосибирской области отказал в иске полностью. В итоге вместо возврата 2 696 000 рублей заказчик получил отказ и обязанность возместить расходы за обе экспертизы. Жалобы в последующие судебные инстанции заказчику не помогли.
Если смотреть на это дело целиком, бросается в глаза одна вещь. Разработчик не готовился к суду заранее, он просто нормально вёл проект. Направлял акты, переписывался по почте, работал через GitLab, передавал исходники. Всё это осело в виде данных, дат, метаданных, писем, и когда дошло до суда, именно эта обычная рабочая история стала доказательной базой.
Заказчик, напротив, сам себя подвёл. Регистрация программы в Роспатенте, публикация приложения в маркетплейсах, сообщение "спасибо, работает" - каждое из этих действий по отдельности можно было бы объяснить. Но в совокупности они разбили легенду истца в этом деле.
Что конкретно работало как доказательство
Обобщим, что в этом деле оказалось решающим:
Акты выполненных работ, направленные своевременно - даже без подписи заказчика
Переписка по электронной почте, которую стороны сами признали юридически значимой в договоре
Протокол осмотра сайта, составленный нотариусом
История репозитория GitLab с метаданными, осмотренный адвокатом
Действия самого заказчика - регистрация в Роспатенте, публикация в маркетплейсах, подтверждение получения результатов в мессенджере
Отдельно отмечу про Asana. В деле упоминается, что заказчик ставил задачи через эту систему. Суд это зафиксировал как факт взаимодействия сторон в рамках договора. Трекер задач в данном случае был не просто инструментом управления проектом, но и источником следов работы по проекту.
Вопросы, которые задают чаще всего
Заказчик подписал акты, но теперь говорит, что результат некачественный. Что делать?
Подписанный акт существенно усложняет оспаривание. Обычно заказчику нужно доказывать недостатки результата (часто через экспертизу), особенно если речь идёт о скрытых дефектах. Суды в таких случаях назначают экспертизу. Если продукт работает, шансы оспорить акт низкие. Дополнительно защищает переписка с заказчиком после подписания. Если он пользовался продуктом и писал по рабочим вопросам, это подтверждает фактическое принятие.
Можно ли обойтись без актов - просто договориться на переписку как подтверждение?
Технически да, если в договоре прямо прописано, что переписка по электронной почте является юридически значимой и подтверждает факт оказания услуг. В разбираемом деле именно такое условие было. Но акты всё равно нужны. Переписка подтверждает процесс, акт фиксирует результат. Лучше иметь и то, и другое.
Что делать, если заказчик перестал выходить на связь и не подписывает акты?
Направить акт ценным письмом с описью и уведомлением о вручении. Зафиксировать письменно, что при отсутствии мотивированного отказа акт считается принятым. Если заказчик уклоняется от подписания, исполнитель может оформить односторонний акт, но его значение будет оцениваться судом вместе с другими доказательствами. Параллельно можно сохранить всю переписку, историю репозитория и любые свидетельства того, что заказчик получил и использовал результат.
