Как заказать мобильное приложение для бизнеса: договор, оплата и гарантии

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

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

Как заказать мобильное приложение для бизнеса и с чего начать

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

Какие бизнес-задачи должно решать будущее приложение

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

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

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

Как определить функционал, бюджет и сроки мобильной разработки

Функционал удобно делить на три группы: то, без чего продукт не имеет смысла; то, что усиливает ценность; и то, что можно отложить на потом. Первая группа становится основой MVP — минимальной версии, которая позволяет проверить бизнес-гипотезу на реальных пользователях и не тратить бюджет на функции, спрос на которые ещё не подтверждён.

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

Что подготовить перед обращением в компанию-разработчика

Минимальный пакет, который сэкономит несколько недель переписки:

• описание бизнес-модели и целевых пользователей;

• ключевые сценарии: что пользователь делает в приложении от первого открытия до целевого действия;

• примеры приложений, которые нравятся или не нравятся, с объяснением почему;

• перечень систем для интеграции: CRM, ERP, учётная система, платёжный провайдер, служба доставки;

• имеющиеся материалы: брендбук, дизайн, API-документация, предыдущие наработки;

• ограничения: дедлайн, бюджет, требования к хранению данных.

Даже без технического задания такой бриф даёт достаточно контекста для предварительной оценки и планирования Discovery. Если вы планируете заказать разработку мобильного приложения с нуля, именно бриф становится первым документом, на который будут ссылаться обе стороны.

Чем разработка мобильных приложений на заказ отличается от готовых решений

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

Разработка мобильных приложений на заказ даёт контроль над функционалом, интеграциями и данными, но требует больших инвестиций и более тщательного договора. Для честного сравнения стоит считать полную стоимость владения (TCO) приложением за два-три года, а не только цену запуска. Это совокупные расходы на подписки, доработки, поддержку, инфраструктуру и стоимость возможной миграции.

Как выбрать разработчика мобильных приложений и проверить подрядчика

Фрилансер, IT-компания или собственная команда: кому доверить проект

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

Нередко оптимальный путь комбинированный: IT-компания запускает продукт, а бизнес параллельно формирует внутреннюю экспертизу, чтобы впоследствии частично забрать развитие в собственную команду. В таком случае требования к документации и передаче кода нужно закладывать в договор с самого начала.

Как оценить портфолио, техническую экспертизу и опыт в вашей отрасли

Скриншоты в портфолио мало что доказывают. Попросите ссылки на опубликованные приложения в App Store и Google Play, посмотрите дату последнего обновления и отзывы. Продукт, который регулярно обновляется годами, свидетельствует о долгосрочном сотрудничестве, а не об одноразовом релизе.

Проверьте опыт именно с вашими интеграциями и ограничениями: платежи, персональные данные, учётные системы, геолокация, офлайн-режим. Спросите, как подрядчик выбирает между нативной разработкой под iOS и Android и кроссплатформенными технологиями вроде Flutter или React Native. Качественный ответ содержит компромиссы: кроссплатформенный подход уменьшает объём кода и стоимость поддержки, а нативный целесообразнее при глубокой работе с аппаратными возможностями устройства или специфических требованиях к производительности. Сильный разработчик мобильных приложений объясняет такой выбор через ваши бизнес-цели, а не через предпочтения команды.

Какие вопросы задать разработчику мобильных приложений перед подписанием договора

• Кто конкретно будет работать над проектом и возможна ли замена специалистов без согласования?

• Как устроено тестирование: отдельный QA, автотесты, проверка на реальных устройствах?

• Где будет храниться код и будет ли у заказчика доступ к репозиторию с первого дня?

• Как оцениваются и согласовываются изменения функционала?

• Как часто проводятся демонстрации промежуточных результатов?

• На чьи аккаунты будет публиковаться приложение и регистрироваться сторонние сервисы?

• Что входит в гарантию и сколько стоит дальнейшая поддержка?

• Какие практики безопасной разработки применяются: code review, статический анализ кода, проверка зависимостей?

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

На какие риски и признаки ненадёжного подрядчика следует обратить внимание

Тревожные сигналы: точная цена без единого уточняющего вопроса; требование 100% предоплаты; отказ открывать репозиторий до финального платежа; размытые формулировки вроде «приложение под ключ» без перечня функций; нежелание фиксировать права на код; отсутствие QA в составе команды.

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

Договор на разработку мобильного приложения: какие условия нужно зафиксировать

Договор на разработку мобильного приложения – главный инструмент защиты бюджета. Он должен описывать не только цену и срок, но и механику сотрудничества: как определяется результат, как вносятся изменения, что происходит при конфликте.

Предмет договора, объём работ и техническое задание

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

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

Сроки исполнения, промежуточные результаты и ответственность сторон

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

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

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

Как прописать порядок внесения изменений в функционал и бюджет

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

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

Кому принадлежат исходный код, дизайн и имущественные права интеллектуальной собственности

Это один из важнейших вопросов проекта. В Украине правовая охрана компьютерных программ подробно урегулирована новым Законом «Об авторском праве и смежных правах» № 2811-IX, а распределение имущественных прав на произведение, созданное по заказу, зависит от норм законодательства и условий договора. Рассчитывать на «по умолчанию» опасно: передача имущественных прав интеллектуальной собственности должна быть прописана прямо.

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

Если исполнитель применяет собственные наработки, которые переходят из проекта в проект, нормальная практика – неисключительная бессрочная лицензия на них для заказчика. Главное, чтобы это было указано прямо, а право собственности на исходный код, созданный именно для вас, не вызывало сомнений.

NDA, конфиденциальность и защита бизнес-данных

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

Условия расторжения договора и возврата неиспользованных средств

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

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

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

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

Fixed Price, Time & Material и Dedicated Team: какую модель оплаты выбрать

Fixed Price и Time & Material часто сочетают: Discovery и MVP – по фиксированной цене, дальнейшее развитие – почасово. Так бизнес получает предсказуемость на старте и гибкость после запуска.

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

Поэтапная оплата за результат: Discovery, дизайн, разработка, тестирование и релиз

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

1. Discovery – документация, прототип, оценка и календарный план.
2. UX/UI-дизайн – согласованные макеты ключевых экранов и дизайн-система.
3. Разработка – оплата по спринтам или модулям после демонстрации работающего функционала в тестовой среде.
4. Тестирование и стабилизация – после закрытия критических дефектов.
5. Релиз – финальный платёж после публикации и передачи кода и доступов.

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

Как согласовывать акты выполненных работ и проверять промежуточные результаты

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

Дополнительные расходы: интеграции, серверы, лицензии и публикация приложения

Смета IT-проекта редко ограничивается работой команды. Отдельно планируются:

• хостинг и облачная инфраструктура для серверной части;

• аккаунты разработчика: годовая подписка Apple Developer Program и разовая регистрация в Google Play Console;

• платные SDK, карты, аналитика, SMS-рассылки, сервисы push-уведомлений;

• комиссии платёжных провайдеров и магазинов приложений;

• доработки на стороне CRM или ERP, если их API не готовы к интеграции.

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

Как избежать превышения сметы и непредвиденных платежей

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

Как проходит разработка мобильного приложения после подписания договора

Этапы разработки мобильного приложения должны быть отражены в календарном плане и связаны с графиком платежей.

Discovery и подготовка технического задания

Команда изучает бизнес-процессы, пользователей и имеющиеся системы, формирует user stories, архитектуру, спецификацию API, оценку и план работ. Здесь же фиксируются технические риски: есть ли у учётной системы стабильный API, нужна ли очередь для синхронизации заказов, как приложение ведёт себя без связи. Отдельно определяются среды (разработки, тестовая, продакшн) и требования к инфраструктуре. Результат Discovery — не только документ, но и обоснованная оценка: после этого этапа стоимость и сроки становятся значительно точнее, чем на первом созвоне, а заказчик может принять решение о запуске разработки с пониманием рисков.

Прототипирование, UX/UI-дизайн и согласование интерфейса

Сначала создаётся кликабельный прототип для проверки сценариев, затем UX/UI-дизайн мобильного интерфейса с учётом рекомендаций Apple и Google для своих платформ. Согласованные макеты становятся частью критериев приёмки, что уменьшает риск споров в стиле “мы ожидали иного”.

Программирование приложения для iOS и Android

Разработка ведётся итерациями с регулярными демонстрациями. Параллельно идёт разработка серверной части: API, админпанель, базы данных, сервис уведомлений. Код хранится в репозитории, к которому у заказчика есть доступ, а сборки через CI/CD разворачиваются на отдельные среды. Каждое изменение проходит code review, а сборка — автоматические проверки.

Интеграция с CRM, ERP, платёжными системами и API

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

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

Тестирование функционала, производительности и безопасности

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

Публикация в App Store и Google Play и передача готового продукта

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

Какие гарантии должен получить бизнес при заказе мобильного приложения

Гарантийное исправление ошибок после запуска

Гарантия на разработку мобильного приложения означает, что исполнитель безвозмездно исправляет дефекты – несоответствия согласованному ТЗ, выявленные в течение определённого срока после приёмки. Она не охватывает новые функции, изменение требований или последствия вмешательства третьих лиц в код.

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

Как зафиксировать гарантийный срок и условия устранения дефектов

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

Гарантии качества, безопасности и соответствия техническому заданию

Помимо исправления ошибок, договор может гарантировать, что код не содержит вредоносных компонентов, не нарушает права третьих лиц, а использованные открытые библиотеки совместимы с коммерческим использованием. Полезно зафиксировать минимальные стандарты качества: code review для каждого изменения, обязательные проверки безопасности при сборке, поддержку согласованных версий iOS и Android.

Что делать, если разработчик нарушает сроки или не выполняет обязательства

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

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

Чем гарантийное обслуживание отличается от платной технической поддержки

Гарантия покрывает дефекты, существовавшие на момент приёмки. Техническая поддержка после запуска – отдельная платная услуга: мониторинг, адаптация к новым версиям iOS и Android, обновление библиотек, мелкие доработки, администрирование серверов. Для неё отдельно согласовывают SLA и сроки реагирования, пакет часов и цену. Путаница в этих понятиях – распространённый источник конфликтов, поэтому границу стоит чётко описать в договоре.

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

Функциональное тестирование и проверка соответствия ТЗ

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

Передача исходного кода, репозиториев, документации и доступов

Передача – это не архив с кодом. Полный пакет обычно содержит:

• репозитории мобильных приложений, серверной части и админпанели с историей изменений;

• инструкции по сборке и развёртыванию, настройки CI/CD;

• техническую документацию: архитектуру, спецификацию API, схему базы данных;

• дизайн-файлы, прототипы, бэклог, записи ключевых решений;

• доступы к серверам, базам данных, аккаунтам сторонних сервисов;

• перечень известных ограничений и технического долга;

• описание интеграций, мониторинга и логирования.

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

Как проверить готовность приложения к реальной нагрузке

Попросите результаты нагрузочного тестирования серверной части на сценариях, близких к реальным: одновременный вход пользователей, пиковые заказы, массовая рассылка уведомлений. Убедитесь, что настроены мониторинг, алерты и резервное копирование базы данных, а на продакшн-среде проходят базовые проверки работоспособности API. Отсутствие мониторинга означает, что о вероятном сбое вы узнаете от клиентов.

Акт приёма-передачи: что должен получить заказчик

Акт приёма-передачи работ фиксирует, что результат соответствует договору, а также переход имущественных прав. Заказчик должен получить подписанный акт, перечень переданных объектов интеллектуальной собственности, документацию и подтверждение передачи доступов. Дату подписания акта удобно сделать датой начала гарантийного срока.

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

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

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

Типичные ошибки бизнеса при заказе мобильной разработки

Начало разработки без подробного технического задания

Без ТЗ невозможно ни точно оценить работу, ни принять её. Любое расхождение в видении становится конфликтом, а Fixed Price без спецификации превращается в спор о том, что «подразумевалось». Discovery обходится значительно дешевле, чем переписывание готового функционала. Даже если бизнес торопится, несколько недель на документацию зачастую оправданы из-за меньшего количества переработок и чётких критериев приёмки.

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

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

Полная оплата проекта до передачи результатов

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

Отсутствие в договоре условий передачи имущественных прав на программный продукт

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

Игнорирование расходов на поддержку, обновление и масштабирование

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

Чеклист заказчика: что проверить перед подписанием договора

Документы, которые нужно согласовать с IT-подрядчиком

• NDA, подписанный до передачи чувствительной информации.

• Основной договор и техническое задание, либо спецификация как приложение.

• Календарный план с контрольными точками.

• Порядок управления изменениями и форма запроса на изменение.

• Условия технической поддержки и SLA, если поддержка нужна после запуска.

Условия оплаты, гарантии и ответственность исполнителя

• Модель оплаты и привязка платежей к этапам.

• Размер аванса, не превышающий стоимости ближайшего этапа.

• Перечень дополнительных расходов и того, кто их оплачивает.

• Гарантийный срок, классификация дефектов и сроки исправления.

• Штрафные санкции и ответственность сторон с разумными лимитами.

• Порядок расторжения и возврата неиспользованных средств.

Контрольные точки, критерии приёмки и отчётность по проекту

• Регулярные демонстрации на тестовой среде.

• Критерии приёмки для каждого этапа.

• Сроки рассмотрения актов и порядок фиксации замечаний.

• Отчёты о потраченных часах и остатке бюджета.

Права на код, доступы и техническая независимость бизнеса

• Явная передача имущественных прав на код, дизайн и документацию.

• Перечень сторонних библиотек и их лицензий.

• Репозиторий, хостинг, аккаунты Apple и Google оформлены на заказчика.

• Согласование субподрядчиков и их обязательства по конфиденциальности.

• Право на независимый аудит кода.

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

FAQ