Договор на разработку приложения: что проверить перед подписанием
Перед подписанием договора на разработку приложения проверьте пять блоков: переход исключительных прав на исходный код, разбивку работ на этапы с приёмкой по каждому, гарантийный срок на бесплатное исправление дефектов, условия поддержки после релиза и порядок расторжения. Размытая формулировка хотя бы в одном пункте — прямой риск потерять и бюджет, и сам продукт.
Почему нельзя подписывать типовой шаблон не глядя
По Закону РК «Об авторском праве и смежных правах» исключительные права на программный код по умолчанию принадлежат тому, кто его написал, — студии или конкретному разработчику. Если в договоре нет отдельного пункта об отчуждении прав заказчику, вы оплачиваете работу, но юридически приложение вам не принадлежит. Это не теория: при продаже бизнеса или привлечении инвестиций первое, что запрашивает юрист другой стороны, — документы на интеллектуальную собственность.
Второй типовой пробел — отсутствие технического задания как приложения к договору. Формулировка «разработка мобильного приложения для iOS и Android» без перечня экранов, ролей пользователей и интеграций означает, что любой спор о составе работ решится не в вашу пользу: суд смотрит на текст договора, а не на переписку в мессенджере. За 300+ проектов с 2007 года команда Applications.kz не раз дорабатывала продукты после разрыва заказчика с прежним подрядчиком — и почти каждая такая история начиналась с договора на полторы страницы.
Права на код: пункт, который дороже всех остальных
Это главный раздел договора. Проверяйте не наличие слова «права», а конкретный юридический механизм их перехода.
Какие формулировки должны быть в тексте
- Отчуждение, а не лицензия. «Исполнитель передаёт заказчику исключительные имущественные права в полном объёме» — корректно. «Предоставляет право использования» — это лицензия: код останется у студии, а вы получите лишь разрешение им пользоваться, иногда срочное.
- Момент перехода прав. Оптимально — поэтапно, после оплаты каждого акта. Формулировка «после полной оплаты по договору» допустима, но тогда любой спор по последнему этапу блокирует права на всё приложение.
- Состав передаваемого. Исходный код, репозиторий, дизайн-макеты, документация API, схема базы данных, конфигурации сборки. Скомпилированное приложение без исходников — это не передача результата.
- Open-source компоненты. Договор должен обязывать исполнителя использовать библиотеки с лицензиями MIT, Apache 2.0, BSD и фиксировать их перечень. Компонент под GPL в коммерческом коде — мина замедленного действия.
Технические аккаунты — на заказчике
Аккаунты Apple Developer, Google Play Console, домен, хостинг и базы данных должны регистрироваться на вашу компанию, а не на подрядчика. Приложение, опубликованное с аккаунта студии, при конфликте превращается в заложника: перенос возможен, но только с согласия владельца аккаунта. Впишите в договор пункт: «Публикация осуществляется с аккаунтов заказчика, доступы передаются по акту».
Этапы, сроки и оплата: деньги привязываем к результату
Стопроцентная предоплата за разработку мобильного приложения — недопустимое условие при бюджете проекта от 4–5 млн ₸ и выше. Рабочая схема — оплата по этапам, где каждый этап закрывается актом и осязаемым результатом, который остаётся у вас даже при расторжении.
| Этап | Результат на выходе | Доля бюджета |
|---|---|---|
| Аналитика и ТЗ | Спецификация, карта экранов, прототип | 10–15% |
| UI/UX-дизайн | Макеты всех экранов в Figma с передачей исходников | 15–20% |
| Разработка | Промежуточные сборки по спринтам, код в репозитории заказчика | 45–50% |
| Тестирование и релиз | Публикация в App Store и Google Play | 10–15% |
| Стабилизация | Исправления по итогам первых 2–4 недель работы | 5–10% |
Ориентиры по бюджетам на рынке Казахстана в 2026 году: MVP — от 4,5 до 9 млн ₸, продукт среднего масштаба с бэкендом и админ-панелью — 12–30 млн ₸, ставка часа специалиста в студиях — 12 000–25 000 ₸. Если смета подрядчика заметно ниже рынка, ищите, на чём планируют экономить: обычно это тестирование и документация — то, что всплывает после релиза.
По срокам проверьте три вещи: календарный план по этапам (а не одна общая дата), правило о приостановке сроков, если заказчик задерживает материалы или согласования, и неустойку за просрочку исполнителя — стандартно 0,1% от суммы этапа за день, с потолком 10%.
Гарантии: кто и за чей счёт чинит баги
Гарантийный раздел отвечает на вопрос, что произойдёт, когда после релиза что-то сломается. Рыночная норма для Казахстана — гарантия от 3 до 12 месяцев с бесплатным исправлением дефектов. Но сам по себе срок ничего не значит без двух уточнений.
Первое — определение дефекта. Дефект — это несоответствие работы приложения техническому заданию. Поэтому без детального ТЗ гарантия не работает: исполнитель всегда сможет заявить, что «так и было задумано». Новые функции, изменение дизайна и доработки под новые версии iOS и Android дефектами не являются — это отдельные платные работы, и честный договор прямо разводит эти понятия.
Второе — сроки реакции. «Исправим в разумный срок» — пустая фраза. Зафиксируйте градацию: критический сбой (приложение не запускается, не проходит оплата) — реакция в течение 4–8 рабочих часов, некритичный дефект — исправление в 5–10 рабочих дней. Отдельно проверьте, что гарантия не сгорает, если вы передали проект на поддержку другой команде по объективным причинам, — хотя на практике правки чужого кода третьими лицами гарантию обычно прекращают, и это справедливо.
Поддержка после релиза: отдельный блок, а не строчка
Приложение — не сайт-визитка: каждый год выходят новые версии iOS и Android, меняются требования сторов, растёт нагрузка. Договор должен отвечать, что происходит после окончания гарантии. Варианты: ежемесячный пакет поддержки (на рынке КЗ — от 150 000 до 600 000 ₸/мес в зависимости от объёма часов и SLA), почасовая оплата доработок по зафиксированной ставке или передача проекта вашей внутренней команде.
Если планируете когда-нибудь забрать продукт внутрь, заранее проверьте пункт о передаче знаний: документация, описание архитектуры, инструкция по развёртыванию. Полезно понимать, из кого состоит команда разработки приложения, — тогда вы сможете оценить, какие роли придётся закрывать самостоятельно и сколько это будет стоить.
Красные флаги: когда договор лучше не подписывать
- Предоплата 100% или 70%+ до начала работ.
- Нет технического задания как приложения к договору — только «разработка приложения» одной строкой.
- Права на код передаются по лицензии или вопрос прав не упомянут вовсе.
- Публикация только с аккаунтов исполнителя, без обязательства передать доступы.
- Отсутствует порядок расторжения и судьба уже оплаченных результатов при разрыве.
- Нет гарантийного срока или дефект не определён через ТЗ.
- Исполнитель — физлицо без ИП/ТОО: взыскать что-либо при споре будет почти невозможно. Чем юридически отличаются форматы работы, мы разобрали в сравнении фрилансер или студия для разработки приложения.
Отдельный совет: запросите у подрядчика проект договора до обсуждения цены. Качество этого документа говорит о процессах компании больше, чем портфолио. Студия, которая 19 лет работает на рынках Казахстана, ОАЭ и Таиланда, присылает договор с ТЗ, календарным планом и разделом о правах — потому что уже проходила все спорные ситуации.
Applications.kz занимается разработкой мобильных приложений в Алматы и по всему Казахстану с 2007 года: 300+ проектов, фиксированные этапы, передача прав по актам. Пришлите описание задачи на +7 (707) 928-13-15 — подготовим смету и проект договора за 24 часа, чтобы вы могли проверить нас по этому же чек-листу.
Частые вопросы
Кому принадлежат права на приложение, если в договоре об этом ничего нет?
По умолчанию — разработчику. Законодательство РК закрепляет исключительные права за автором кода, пока они не переданы письменным договором. Оплата работ сама по себе права не переносит. Если договор уже подписан без этого пункта, заключите дополнительное соглашение об отчуждении исключительных прав — добросовестный подрядчик подпишет его без проблем.
Какая схема оплаты считается нормальной для рынка Казахстана?
Поэтапная: аванс 15–30% на старте, далее оплата по актам за каждый закрытый этап — дизайн, разработка, релиз. При бюджете 5–30 млн ₸ это защищает обе стороны: заказчик платит за принятый результат, исполнитель не кредитует проект из своего кармана. Постоплата 50/50 встречается, но обычно у студий с длинной репутацией.
Сколько должна длиться гарантия на приложение?
От 3 до 12 месяцев после подписания финального акта. Меньше трёх месяцев — мало: часть дефектов проявляется только под реальной нагрузкой и на редких устройствах. Важно, чтобы договор определял дефект как отклонение от ТЗ и отделял гарантийные исправления от платных доработок и обновлений под новые версии операционных систем.
Можно ли расторгнуть договор в середине проекта и забрать наработки?
Да, если это прописано. Проверьте порядок расторжения: уведомление за 10–30 дней, взаиморасчёт по фактически выполненным работам и обязательная передача всех оплаченных результатов — кода, макетов, документации. Без такого пункта при разрыве вы рискуете остаться с актами об оплате, но без единого файла на руках.
Что входит в поддержку после релиза и сколько она стоит?
Мониторинг работоспособности, исправление новых дефектов, обновления под свежие версии iOS и Android, мелкие доработки в пределах пакета часов. На рынке Казахстана пакеты стоят от 150 000 до 600 000 ₸ в месяц, разовые доработки — по ставке 12 000–25 000 ₸ за час. Условия и SLA фиксируются отдельным договором или приложением.