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

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

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

Предмет договора на разработку приложения: короткий документ вместо общих слов

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

Поэтому предметом становится короткий документ: экраны, интеграции, границы первой версии и срок. У нас он появляется после часового разговора и прикладывается к договору как его предмет — ровно для того, чтобы «мы думали, это входит» не всплыло на середине. Обе стороны читают его целиком, а не пролистывают.

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

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

Этапы и оплата: сколько вы должны в каждый момент проекта

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

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

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

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

Приёмка мобильного приложения: что вы принимаете на каждом этапе

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

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

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

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

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

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

Права на код: что говорит закон и где лежит репозиторий

Статья 1296 Гражданского кодекса о произведениях, созданных по заказу, по умолчанию стоит на стороне заказчика. Исключительное право на программу, созданную по договору, предметом которого было её создание, принадлежит заказчику, если договор не предусматривает иное. Подрядчик при этом вправе использовать программу для собственных нужд по безвозмездной простой (неисключительной) лицензии в течение всего срока действия исключительного права — тоже если договор этого не исключает.

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

Закон при этом не кладёт код вам в руки. На практике проверьте три вещи: репозиторий заведён в вашей организации с первого коммита, а не передаётся архивом в конце; инфраструктура живёт в ваших аккаунтах; внутри нет платформы, лицензии или подписки подрядчика, без которой проект перестанет собираться. У нас уход от студии должен стоить одного созвона по передаче, а не переписывания системы.

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

Аккаунты разработчика, ключи подписи и публикация в сторах

Приложение в сторе живёт в аккаунте разработчика Apple или Google и подписано ключом. Обновление выпускает тот, у кого есть и аккаунт, и ключ. Если подрядчик заводит их на себя, однажды вы окажетесь заперты вне своего продукта: это скучная деталь ровно до того дня, когда приложение нужно обновить, а подрядчик недоступен.

Запишите в договор, что аккаунты Apple и Google, ключи подписи и сертификаты оформлены на заказчика с первой недели, а подрядчик получает к ним доступ как подрядчик. Мы аккаунты разработчика на себя не оформляем: продукт должен оставаться вашим.

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

Если в приложении есть оплата, способ приёма денег тоже должен укладываться в правила стора, иначе на ревью возникнут вопросы. Как это устроено, разобрано в статье о том, как устроены платежи в приложении.

Гарантия и поддержка: два разных пункта договора

Гарантия отвечает на вопрос, кто платит за ошибки в уже сданной работе. У нас это шесть месяцев после сдачи: ошибки правим за свой счёт. Бесконечные правки без нового объёма в гарантию не входят — наши ошибки остаются гарантией, а новая задача становится новым этапом.

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

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

Выход из проекта после любого этапа

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

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

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

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

Десять вопросов, которые стоит пройти с подрядчиком и юристом до подписи:

  • Предмет договора — короткий документ с экранами, интеграциями, границами первой версии и сроком.
  • В том же документе есть список того, что в первую версию не входит.
  • Оплата разбита на этапы, у каждого своя сумма и свой результат; нет ни полной предоплаты, ни оплаты целиком в конце.
  • Сумма этапа не растёт без изменения объёма, а изменение пересчитывается до начала работ.
  • Результат каждого этапа вы проверяете на своём телефоне, и этап закрывается промежуточным актом.
  • Репозиторий заведён в вашей организации с первого коммита, платформы и подписки подрядчика внутри нет.
  • Аккаунты Apple и Google, ключи подписи и сертификаты оформлены на вас с первой недели.
  • Сроки ревью не записаны как обязательство подрядчика, а релиз стоит в плане с запасом.
  • Гарантия на ошибки и поддержка после релиза описаны разными пунктами, поддержка оформлена отдельным договором.
  • Остановиться можно после любого этапа, и сделанное остаётся у вас.

Если на все десять вопросов есть ответ, юристу остаётся работа над формулировками, а не над смыслом договора.

Следующий шаг — описание приложения на одну страницу: за 12 часов пришлём расчёт стоимости и состав первой версии. Первый релиз с одним сценарием на обеих платформах стоит от 800 000 ₽ и занимает восемь недель. Дальше — разговор на час и тот самый короткий документ, который станет предметом договора.