Как принять незавершённый сайт или интеграцию у другого подрядчика

Что делать, если проект бросили на полпути, а вам нужно его забрать и передать другому исполнителю

Незавершённый сайт или интеграцию нельзя принимать так же, как готовый проект — здесь нет финального результата, который можно сверить с ТЗ. Сначала нужно юридически зафиксировать факт прекращения работы с текущим подрядчиком и объём выполненного, затем технически описать реальное состояние кода, данных и доступов, и только после этого передавать проект новому исполнителю. Ключевые риски — недоказанный объём работ, отсутствие прав на код, домен и хостинг на чужом аккаунте, и скрытые технические проблемы, которые всплывают уже после того, как прежний подрядчик недоступен.

В чём проблема и кому полезна статья

Подрядчик пропал, разругался с заказчиком, обанкротился или просто не справился — а на руках остаётся сайт с частично написанным кодом, наполовину настроенная интеграция с 1С или CRM, и куча вопросов: что из этого вообще работает, кому принадлежит код, где лежат домен и база данных и как объяснить это новому исполнителю, который придёт заканчивать проект.

Ситуация отличается от обычной приёмки готовой работы. Обычно заказчик сверяет сданный результат с техническим заданием, подписывает акт или пишет мотивированный отказ. Здесь же результата в привычном смысле нет — есть незавершённый артефакт, состояние которого сам заказчик чаще всего не может оценить самостоятельно. Материал будет полезен владельцам бизнеса, руководителям digital-направлений и техническим специалистам, которым предстоит принять решение по проекту, оставшемуся без подрядчика.

Что происходит на практике

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

Разработчики, разбиравшие похожие ситуации, отмечают, что унаследованный код часто оказывается не приспособлен для доработки: логика может быть перемешана с отображением, а элементы, казавшиеся одинаковыми на макетах, на деле требуют значительно больше работы, чем предполагалось изначально [1]. Это первый практический вывод: пока проект не осмотрен изнутри — техническим специалистом, а не только на уровне «работает / не работает» в браузере — оценить его реальное состояние невозможно.

Как устроен процесс: юридическая сторона

Приёмка результата и отказ от договора — это разные вещи

Если работы выполнены полностью или почти полностью, но с недостатками, применяется классическая процедура приёмки по ст. 720 ГК РФ: заказчик обязан осмотреть результат работы и при обнаружении отступлений от договора немедленно заявить об этом подрядчику [2]. Если подрядчик подготовил акт сдачи-приёмки, а заказчик от него уклоняется без объяснения причин, подрядчик вправе подписать акт в одностороннем порядке — и суды признают такой акт недействительным только если мотивы отказа заказчика были обоснованы [3]. Это значит: если проект действительно не доделан, заказчику важно письменно и предметно зафиксировать конкретные недостатки и невыполненный объём, а не просто промолчать или сослаться на общее недовольство.

Но если проект брошен на середине и подрядчик его вообще не предъявляет к сдаче, ситуация другая: это не приёмка с недостатками, а фактическое прекращение отношений. Заказчик по договору подряда вправе в любой момент до сдачи ему результата работы отказаться от исполнения договора, уплатив подрядчику часть цены пропорционально выполненной работе — эта возможность прямо описывается юристами как менее затратный способ прекращения отношений по сравнению с расторжением договора оказания услуг [4]. Практикующие юристы отдельно подчёркивают, что тип договора — подряд, оказание услуг или смешанный договор с элементами лицензионного — определяет саму возможность одностороннего отказа и порядок расчётов [5], поэтому первый шаг — не аудит кода, а внимательное прочтение самого договора и определение его правовой природы.

Ключевые причины, по которым заказчики чаще всего идут на досрочное расторжение — нарушение сроков, невыполнение работ в полном объёме и неудовлетворительное качество [6]. Важно понимать, что закон даёт заказчику право отказаться от договора без объяснения причин, но при этом сохраняется риск, что придётся возместить подрядчику часть убытков или потерять внесённый аванс — конкретный расклад зависит от условий договора и доказанного объёма выполненного [6].

Права на код, дизайн и данные

Отдельный и часто упускаемый вопрос — кому принадлежат исключительные права на уже написанный код и созданные материалы. По умолчанию право на программу для ЭВМ или иное произведение, созданное по заказу, принадлежит заказчику, если договором не предусмотрено иное [7]. Но если исключительное право прямо передано заказчику, подрядчик всё равно сохраняет право использовать созданное произведение для собственных нужд на условиях безвозмездной простой лицензии, если договор не говорит об обратном [8]. Для незавершённого проекта это означает: нужно явно прописать в акте или дополнительном соглашении, что именно передаётся — весь код целиком, включая незаконченные модули, черновики и промежуточные версии, а не только «финальная» часть, которой формально не существует.

Юристы отдельно отмечают, что права на материальный носитель, на котором передан результат — флешку, репозиторий, архив — не тождественны интеллектуальным правам на сам продукт [9]. Получить доступ к git-репозиторию физически не значит автоматически получить право дорабатывать и коммерчески использовать код — это стоит закрепить письменно, отдельно от простой передачи файлов.

Техническая сторона: что на самом деле сделано

Технический аудит как обязательный шаг

Смена подрядчика — одна из типовых, прямо называемых причин для проведения технического аудита кода: новому подрядчику важно понять, в каком состоянии находится приложение [10]. Такой аудит обычно включает разбор архитектуры (диаграммы классов или иное структурное описание того, как устроено приложение), проверку соответствия требованиям к хранению данных и согласиям пользователей, а также сканирование кода на уязвимости [11].

Для интернет-магазинов и сайтов на готовых CMS аудит перед передачей включает более практичные пункты: проверку кода на уязвимости, анализ базы данных, проверку производительности, кэширования и логов [12]. Отдельно стоит зафиксировать список установленных модулей и их версий — без этого списка новый подрядчик рискует случайно обновить компонент, который сломает уже настроенную интеграцию, например с 1С [12].

Приёмка сайта или интеграции своими силами

Есть практические приёмы, которые снижают риск ложного впечатления о готовности проекта. Один из главных — не принимать проект с экрана и учётной записи прежнего подрядчика: там могут быть сохранены пароли и кеш, из-за чего всё «работает», а с чужого устройства картина окажется другой [13]. Другая типичная ошибка — проверять только главную страницу или самые заметные части системы, готовящиеся «к показу», тогда как проблемы прячутся в менее заметных разделах и проявляются через недели или месяцы после ухода подрядчика [13]. Резкое ускорение сдачи против изначального плана — тоже сигнал проверять придирчивее [13].

Перед финальной приёмкой стоит убедиться, что у заказчика есть доступ ко всем важным элементам проекта, а не только к готовому интерфейсу [14]. Речь идёт не только о самом сайте, но и об административных панелях, репозиториях кода, тестовых и продуктивных базах данных, учётных записях в системах мониторинга и логирования.

Российская специфика

Домены, хостинг и доступы

Отдельная категория рисков — активы, которые оформлены не на заказчика, а на подрядчика или его сотрудника. Практикующие специалисты советуют минимальный набор доступов, которые нужно получить или проверить при смене исполнителя: доступ к FTP/SSH, административной панели CMS, базе данных, панели хостинга, регистратору домена и корпоративным сервисам, привязанным к домену [15]. Если хостинг и домен настроены на аккаунт подрядчика, минимально безопасный вариант — перенести сайт и базу данных на собственный хостинг заказчика и отдельно урегулировать смену администратора домена [16]. Через панель хостинга при желании можно получить доступ к файловой системе и базе данных сайта, поэтому наличие полного контроля именно над доменом и хостингом — а не только над админкой CMS — практики называют критически важным [15].

Важное и недавнее изменение: с 1 сентября 2026 года смена администратора домена в российских зонах .RU, .РФ и .SU требует подтверждённой учётной записи в ЕСИА (Госуслугах) у нового администратора, тогда как до этой даты процедура проходила по прежним, более простым правилам [17]. Если проект принимается сейчас и домен зарегистрирован не на компанию-заказчика, стоит проверить это как можно раньше и не откладывать переоформление.

Приёмка по ГК РФ: акты и мотивированные отказы

Российское право не описывает подробно саму процедуру приёмки — детали почти полностью отдаются на откуп договору [18]. Это значит, что качество договора, заключённого с прежним подрядчиком (и который стоит заключить с новым), напрямую определяет, насколько защищённой окажется компания в спорной ситуации. Если заказчик считает работы невыполненными или выполненными некачественно, стандартный инструмент защиты — направить подрядчику письменный мотивированный отказ от подписания акта с конкретными, а не общими претензиями [19]. Верховный Суд последовательно указывает, что бремя доказывания обоснованности отказа лежит на заказчике [20], поэтому расплывчатые формулировки вроде «нас не устраивает качество» без конкретики рискованны.

Независимая экспертиза как способ снять спор

Если стороны расходятся в оценке объёма и качества выполненного настолько, что дело идёт к спору или суду, можно заказать независимую экспертизу программного обеспечения — она анализирует исходный код, документацию и соответствие технического результата техническому заданию [21]. Такая экспертиза может проводиться как судебная — на основании закона о государственной судебно-экспертной деятельности, так и досудебная, для урегулирования спора без обращения в суд [22]. Это не обязательный, но полезный инструмент в случаях, когда прежний подрядчик оспаривает объём выполненных работ, а самостоятельная техническая оценка заказчика или нового исполнителя не воспринимается как беспристрастная.

Варианты реализации: что делать с недоделанным проектом

Обычно есть три пути:

• Достроить существующий код. Подходит, если аудит показал, что архитектура в целом здоровая, документация и структура понятны, а объём переделки некритичен.
• Переписать проект заново, использовав часть логики и контента. Стоит рассматривать, если код действительно непригоден для развития — например, бизнес-логика перемешана с отображением, а изменения требуют кратно больше усилий, чем доработка [1].
• Заказать независимый аудит или экспертизу перед принятием решения. Уместно, когда сумма проекта значительна, стороны конфликтуют по объёму выполненного, а внутренней технической экспертизы у заказчика недостаточно, чтобы принять решение самостоятельно [10], [21].

Какой из вариантов выбрать, зависит от конкретного проекта: универсального ответа «всегда переписывать» или «всегда доделывать» нет, и решение обычно принимается уже после аудита, а не до него.

Практические этапы приёмки незавершённого проекта

1. Зафиксировать состояние проекта на момент прекращения работ. Сделать полную резервную копию файлов и базы данных, снять снапшот репозитория и зафиксировать дату и состояние — до любых дальнейших правок с любой стороны.
2. Разобраться с правовой природой договора и основанием прекращения отношений — приёмка результата с недостатками (ст. 720 ГК РФ) или односторонний отказ от исполнения договора, поскольку от этого зависит порядок оплаты и юридические риски [2], [4].
3. Направить прежнему подрядчику письменный мотивированный документ — акт с перечнем недостатков и невыполненного объёма либо уведомление об отказе от договора, избегая общих и неконкретных формулировок [19].
4. Собрать полный список активов и доступов: домен и регистратор, хостинг и панель управления, FTP/SSH, база данных, репозиторий кода, административные учётные записи CMS, интеграционные ключи API, почтовые сервисы, привязанные к домену [15], [16].
5. Проверить права на домен и при необходимости начать процедуру смены администратора — заранее, с учётом новых требований к ЕСИА, вступающих в силу с 1 сентября 2026 года [17].
6. Закрепить передачу исключительных прав на созданный код, дизайн и контент отдельным пунктом акта или дополнительным соглашением, а не полагаться на факт передачи файлов [7], [9].
7. Провести технический аудит того, что реально сделано: архитектура, соответствие ТЗ, безопасность кода, состояние базы данных, работоспособность интеграционных методов [11], [10].
8. Проверить проект «с чистого листа» — с другого устройства и без сохранённых у прежнего подрядчика паролей, проверяя не только главную страницу, но и второстепенные разделы [13].
9. При спорном объёме выполненного — заказать независимую экспертизу до обращения в суд или как аргумент в досудебном урегулировании [21], [22].
10. Передать новому подрядчику итоговый пакет: доступы, документацию по итогам аудита, права на код, а также описание того, что подтверждено как рабочее, а что требует переделки.

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

Ограничения, ошибки и риски

• Подписание акта «на слово», без реальной проверки — самая частая и дорогая ошибка: деньги переведены, подрядчик свободен, а список недоделок остаётся устной договорённостью, которую невозможно предъявить впоследствии [13].
• Домен или почта, зарегистрированные на постороннее лицо, возвращаются гораздо дольше и сложнее, чем переделывается сайт [13].
• Отсутствие письменного мотивированного отказа при несогласии с качеством или объёмом работ — риск того, что односторонний акт подрядчика будет иметь силу в суде [3], [20].
• Отсутствие в договоре прямого условия о передаче исключительных прав — риск того, что прежний подрядчик формально сохранит права на использование части кода даже после передачи файлов заказчику [7], [8].
• Обновление модулей или компонентов новым подрядчиком без списка версий, из-за чего может сломаться уже настроенная интеграция, например с 1С — частая проблема на стороне готовых CMS [12].
• Совмещение приёмки готового результата и приёмки брошенного на середине проекта как одной и той же процедуры — юридически и практически это разные ситуации, требующие разных документов и разного порядка действий [4].

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

Как выбрать решение

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

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

Вывод

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

Источники

[1] qna.habr.com — Существует ли практика передачи выполненного на половину проекта? — https://qna.habr.com/q/50052

[2] consultant.ru — ГК РФ Статья 720. Приемка заказчиком работы, выполненной подрядчиком — https://www.consultant.ru/document/cons_doc_LAW_9027/48e02faf6357243a0fa7806dd7ca2dc2493301a8/

[3] uslugijurista.ru — Строительные споры. Отказ заказчика от приемки работ — https://uslugijurista.ru/stroitelnye-spory-otkaz-zakazchika-ot-priemki-rabot-i-podpisaniya-akta-vypolnennykh-rabot-kak-zakazchiku-obosnovat-i-motivirovat-otkaz-ot-podpisaniya-akta

[4] advgazeta.ru — Как правильно заключить договор на разработку сайта? — https://www.advgazeta.ru/ag-expert/advices/kak-pravilno-zaklyuchit-dogovor-na-razrabotku-sayta/

[5] it-lex.ru — Спор по договору на разработку сайта — https://www.it-lex.ru/news_law?id=244

[6] etalon-cons.ru — Как заказчику расторгнуть договор подряда и не потерять деньги — https://www.etalon-cons.ru/blog/kak-rastorgnut-dogovor-podryada-i-ne-poteryat-dengi/

[7] it-lex.ru — Как сохранить авторские права на программу, созданную по заказу — https://www.it-lex.ru/article/kak-sohranit-avtorskie-prava-programmu

[8] consultant.ru — ГК РФ Статья 1297. Произведения, созданные при выполнении работ по договору — https://www.consultant.ru/document/cons_doc_LAW_64629/ffe44723c03de1b395664b77726f363ca19adb13/

[9] ezybrand.ru — Как выбрать договор на разработку программного обеспечения и веб-сайта — https://ezybrand.ru/blog/kak-vybrat-dogovor-na-razrabotku-po-sajta/

[10] companies.rbc.ru — Технический аудит качества кода: кому нужен и как его правильно проводить — https://companies.rbc.ru/news/64oOw7Zjwj/tehnicheskij-audit-kachestva-koda-komu-nuzhen-i-kak-ego-pravilno-provodit/

[11] habr.com — Чек-лист: технический аудит IT проекта — https://habr.com/ru/articles/791596/

[12] opencart-cms.ru — Проверка OpenCart перед передачей подрядчику: чек-лист — https://opencart-cms.ru/blog/proverit-opencart-pered-peredachey-podryadchiku/

[13] amidcode.com — Чек-лист приемки сайта от разработчика — https://amidcode.com/ru/blog/chek-list-priemki-sajta/

[14] rdbx.ru — Как правильно провести приемку ИТ-проекта: полное руководство — https://rdbx.ru/posts/16

[15] altera-media.com — Как сменить SEO-подрядчика: какие доступы необходимо запросить? — https://www.altera-media.com/information/expert/kak-smenit-seo-podryadchika-s-minimalnymi-poteryami/

[16] blog.kinetica.su — Что запросить при смене подрядчика на интернет-маркетинг? — https://blog.kinetica.su/sovety/zapros_podryad/

[17] telemark-it.ru — Домены и Госуслуги с 1 сентября 2026: инструкция для владельцев сайтов — https://www.telemark-it.ru/blog/domeny-ru-i-gosuslugi/

[18] 101-app.com — Правила приемки работ по договору подряда — https://101-app.com/blog/rules-for-work-acceptance

[19] vegaslex.ru — Как отбиться от требований подрядчика, предъявившего односторонние акты приемки — https://www.vegaslex.ru/mobile/analytics/publications/55820/

[20] vitvet.com — Односторонний акт приёмки работ: как оформить и взыскать оплату — https://vitvet.com/articles/stroitelnyj_podryad/akt_priyomki_rabot/

[21] sudexpa.ru — Независимая экспертиза программного обеспечения (IT-продукта) для суда — https://sudexpa.ru/expertises/ekspertiza-protcessa-razrabotki-i-ispolzovaniia-programmnogo-obespecheniia/

[22] olimp-ekspert.ru — Независимая экспертиза программного обеспечения в Москве — https://olimp-ekspert.ru/ekspertiza-programmnogo-obespecheniya/