Договор на разработку и дизайн приложения

Мобильное или десктоп-приложение – сложнее, чем сайт, потому что может включать написание оригинального кода, работу под конкретные ОС (Android, iOS), дизайн интерфейса, тестирование на разных устройствах. Договор на разработку приложения схож с договором на сайт, но есть свои нюансы.

Важные моменты договора на разработку приложения:

• Чётко указать, какое приложение и под какую платформу: Например: "Разработка мобильного приложения 'SuperApp' для операционных систем iOS и Android, включая дизайн интерфейса, программирование и тестирование".
• Если только под одну ОС – указываете конкретно. Если кроссплатформенное – оговорить.

ТЗ (техническое задание):

• Описание функционала приложения: перечень основных функций и модулей (например, регистрация пользователей, чат, геолокация, интеграция с камерой, push-уведомления и т.д.).
• Платформы, версии: под iOS (версия iOS 15+?) и Android (SDK уровень, например, Android 11+).
• Требования к дизайну UI/UX: возможно, у заказчика есть гайдлайны или референсы. Оговаривается, будет ли исполнитель делать прототипы и макеты экранов на утверждение (желательно – да, и заказчик утверждает).
• Используемые технологии: нативная разработка (Swift/Objective-C, Java/Kotlin) или кроссплатформенная (React Native,Flutter, etc.). Это важно, чтобы потом не было претензии "а я хотел на нативе".
• Интеграции: с сервером (API), сторонними сервисами (например, карты Google, платежные системы). Нужно указать, кто предоставляет API и документацию (обычно заказчик, если есть бэкенд).
• Планируемая нагрузка (сколько пользователей), если релевантно, чтобы понимать требования производительности.
• Требования к безопасности: авторизация, шифрование, хранение данных.
• Дизайн: если входит в работу, то прописать: разработка не менее N уникальных экранов интерфейса, в едином стиле, с адаптацией под разные размеры экранов.
• Тестирование: на каких устройствах будет тестироваться (списокмоделей или размеров экранов).
• Результат: готовое apk и/или ipa (файл приложения) + исходный код. Очень важно: заказчик должен получить исходники, иначе он будет привязан навеки к разработчику.
• Документация: будет ли исполнитель предоставлять техническую документацию, инструкцию по сборке/развертыванию, API doc. Лучше указать, что базовая документация – комментарии в коде + небольшое описание архитектуры – должна быть.

Сроки и этапы:

• Этап 1: Проектирование, прототип (до такой-то даты).
• Этап 2: Дизайн макетов– предоставить X экранов на утверждение (срок).
• Этап 3: Разработка функционала – промежуточная версия(MVP) к такому-то сроку (например, через 2 месяца).
• Этап 4: Тестирование и отладка – до такого-то.
• Этап 5: Публикация (если оговорено, что исполнитель помогает разместить в App Store/ Google Play).
• График лучше согласовать, и прописать, что изменение сроков возможно при согласовании изменений ТЗ.

Приёмка:

• Может быть поэтапная (принят дизайн отдельно актом,потом бета-версия, потом финал).
• Итоговая приёмка: заказчик тестирует приложение (обычно предоставляется testflight для iOS или apk для Android). Указывает баги и несоответствия ТЗ.
• Исполнитель исправляет баги.
• Затем подписывается акт, что приложение принято.

Оплата

• Обычно крупные проекты – поэтапная оплата. Например, 30% аванс, 30% после предоставления прототипа/дизайна, 40% – после финальной сдачи.
• Можно привязать к функционалу: "После реализации функционала A, B, C – выплата такой- то суммы".
• Стоимость должна учесть и разработку, и дизайн, и тестирование – лучше в договоре разбить по частям (сколько за дизайн, сколько за разработку), чтобы если проект остановится на полпути, было понятно, сколько заплатить за уже сделанное.

Права интеллектуальной собственности

• Ещё критичнее, чем с сайтом– код приложения, дизайн интерфейса (графика), может быть контент – все права должны перейти заказчику.
• Прописать: исключительные права на исходный код приложения, дизайн UI, графические элементы, созданные исполнителем, передаются заказчику. Исполнитель гарантирует, что он автор или имеет права использовать все компоненты.

Open source компоненты

• Если разработчик использует сторонние библиотеки – в договоре лучше упомянуть: "Использование сторонних open-source библиотек допускается при условии, что их лицензии не препятствуют коммерческому использованию (MIT, Apache или аналогичные). Исполнитель обязуется предоставить список сторонних библиотеки их лицензий." Это важно: чтобы не оказалось, что он втянул GPL библиотеку, и у заказчика теперь проблемы с лицензированием.
• Мобильные приложения могут содержать шрифты, иконки – нужно, чтобы всё было либо с лицензиями, либо оригинальное.

Конфиденциальность

Обязать не разглашать информацию о проекте, данные API, etc. В
IT это зачастую стартап – важно, чтобы до релиза ничего не утекло.

Гарантия и сопровождение

• Обычно оговаривают гарантийный период (3-6 месяцев) на исправление багов, выявленных при эксплуатации, бесплатно.
• Возможно, опция техподдержки: например, исполнитель может за отдельную плату заниматься обновлениями приложения (новые версии OS, изменение требований AppStore).
• Если нужно размещение в магазинах – указать, помогает ли исполнитель публиковать (для Apple нужен dev аккаунт заказчика, тут взаимодействие).

Неустойки и ответственность

• За срыв сроков – штрафы, как с сайтом (процент в день).
• За невыполнение отдельных этапов – может быть право заказчика расторгнуть договор и потребовать возврат части денег.
• За качество: можно указать, что если приложение не прошло модерацию App Store/Google Play по причинам, связанным с качеством кода (баги, крэши) – исполнитель обязан доработать. (Но если не прошло из-за политики контента или проблем имени – это на заказчике, тут разделить).
• Заказчик отвечает за достоверность исходных данных (например, если API у заказчика кривой, и из-за этого задержки – разработчик не виноват).
• Заказчик также может быть обязан вовремя проводить тестирование и давать фидбек – иначе сроки сдвигаются. Прописать, что, например, "Если заказчик в течение N дней не предоставляет список замечаний или подтверждение приёмки очередной версии, версия считается условно принятой, и разработчик вправе продолжать по плану".

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

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

Beta-тесты и участие третьих лиц: Если, скажем, предусмотрено бета-тестирование с ограниченной группой пользователей – оговорить, кто это организует.

Статус исполнителя: Он может быть компанией или ИП, или физлицо. Если физлицо – оформлять как авторский заказ (тогда НДФЛ), либо рекомендовать ему оформить ИП.

Юрисдикция App Stores: Интересный момент – иногда нужно, чтобы имя разработчика на площадке было заказчика. Нужно прописать, что заказчик предоставляет доступ к своему dev аккаунту Apple/Google, а исполнитель загружает приложение от его имени (под NDA, конечно). Чтобы потом не было, что приложение залито от аккаунта разработчика, и заказчик не имеет к нему доступ.

Совет эксперта

Договор на разработку приложения должен предусмотреть постпроектную жизнь. То есть, не только "написали и забыли", а что будет дальше: право на обновления, кто будет поддерживать, что если через полгода обнаружится критический баг (лучше договориться, что в рамках гарантии исправят).

Особо обращаю внимание на open-source: разработчики любят использовать готовые библиотеки. Это ускоряет работу, но юридически важно лицензии – например, GPL может заставить открыть исходники всего вашего приложения, чего вы не хотите. В договоре можно прямо запретить использовать компоненты с лицензией GPL или похожими копилефтными. Пусть юрист проверит, какие лицензии допустимы (обычно MIT, BSD, Apache – ок).

И не забывайте: UI/UX дизайн – это тоже интеллектуальная собственность. Если исполнитель делает дизайн, убедитесь, что получите исходники дизайна (Figma, Photoshop – макеты), и права на них тоже переходят вам.

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