Разработка мобильных приложений

Кейс клиента: стартап, который не взлетел
Владелец небольшого логистического бизнеса из Ростова-на-Дону решил заказать мобильное приложение для отслеживания грузов у фриланс-команды. Бюджет был ограничен — 350 000 рублей, сроки — 2 месяца.
На старте было только текстовое описание на 3 страницы без макетов и прототипов. Подрядчик пообещал «всё включено», но в договоре не было ни единой цифры: ни по количеству экранов, ни по времени отклика сервера.
Через 4 месяца проект был готов только на 60%. Приложение вылетало при загрузке списка из 50 заказов, а интеграция с 1С работала с задержкой в 10 минут вместо 1 секунды. Клиент остался без денег и без продукта.
Главная ошибка: путаница между гарантиями и обещаниями
На рынке разработки мобильных приложений есть два типа гарантий: фактические (прописанные в договоре) и маркетинговые (озвученные на созвоне). Большинство подрядчиков используют второй тип: «если что, доделаем», «сроки плавающие», «проблемы решим по ходу».
Фактическая гарантия должна включать конкретные сроки устранения багов (например, 48 часов на критический дефект), фиксированную ставку штрафа за срыв этапа (1–2% от стоимости за каждый день просрочки) и перечень параметров производительности (время загрузки экрана, скорость API, поддержка версий ОС).
Если подрядчик отказывается включать эти пункты в договор — это прямой сигнал, что вы рискуете получить «сырой» продукт и бесконечные доработки за свой счет.
Как проверить подрядчика до старта: 6 конкретных шагов
Ниже — список действий, которые должен сделать каждый заказчик до подписания договора. Пропуск хотя бы одного пункта увеличивает риск срыва в 2–3 раза.
- Требуйте прототип на 3-5 основных экранах — не в Figma, а кликабельный на телефоне. Если подрядчик не может сделать прототип за 2–3 дня — он не понимает ваш бизнес.
- Проверьте портфолио на идентичность — скачайте 2–3 приложения из App Store, которые указаны в портфолио, и проверьте их реальные оценки и дату последнего обновления. Приложения-«призраки» с 1.5 звездами — красный флаг.
- Запросите ссылки на 2–3 проектов в работе — не на завершенные, а на текущие. Поговорите с клиентом напрямую о том, как соблюдались сроки и решались споры.
- Уточните методологию разработки — Scrum или Waterfall. Для мобильных приложений оптимален Scrum с демо каждые 2 недели. Waterfall для сложных продуктов означает «увидим результат только в конце».
- Оцените систему контроля версий — доступ к GitHub/GitLab репозиторию должен быть у вас. Без него вы не сможете передать исходники другому разработчику.
- Протестируйте коммуникацию — задайте подрядчику технический вопрос по вашему проекту (например, «какой API лучше использовать для геолокации»). Скорость и качество ответа покажут реальный уровень компетенций.
Договор на разработку: 5 пунктов, без которых не подписываем
Многие заказчики пренебрегают юридической стороной, полагаясь на «честное слово» или «репутацию». Результат — невозвратные предоплаты в 50–70% и судебные разбирательства на 6–12 месяцев.
Вот минимальный набор пунктов, которые должны быть в договоре на разработку мобильного приложения:
- Четкое описание объема работ — по каждому экрану: какие элементы интерфейса, логика переходов, интеграции с внешними сервисами. Всё, что не описано, считается дополнительной работой и оплачивается отдельно.
- Фиксированные сроки с привязкой к этапам — «разработка бэкенда до 15 апреля 2026», «альфа-версия до 10 мая 2026». Без привязки к календарным датам сроки превращаются в растяжимые.
- Порядок приёмки работ — каждый этап принимается в течение 3–5 рабочих дней после передачи. Если подрядчик не исправляет замечания за 3 дня — этап считается просроченным с начислением штрафа.
- Пени и штрафные санкции — 1–2% от стоимости этапа за каждый день просрочки. Максимум — 20–30% от общей суммы договора. Без штрафов подрядчик будет переносить сроки бесконечно.
- Передача исходного кода и прав — после полной оплаты вы получаете исходный код и исключительные права на него. Если подрядчик «забывает» передать репозиторий — он нарушает договор.
Реальный бенчмарк: что можно получить за бюджет до 1 млн рублей
Типичные заблуждения клиентов: «за 300 тысяч сделают как Uber» или «нам нужно срочно, сделайте за месяц». Реалии рынка разработки в 2026 году таковы:
За 300–500 тысяч рублей — приложение с 10–15 экранами, простой бэкенд на Firebase или AWS Amplify, стандартный UI без кастомной анимации. Срок — 2–3 месяца. Гарантийный период — обычно 1 месяц на исправление багов.
За 500–800 тысяч рублей — приложение с 20–30 экранами, сложной бизнес-логикой (система лояльности, реферальные программы), интеграцией с ERP/CRM и своими серверами. Срок — 4–5 месяцев.
За 1 млн+ рублей — полноценная платформа с кастомным дизайном, высокой нагрузкой (1000+ одновременных пользователей), микросервисной архитектурой и полным циклом тестирования. Гарантия — 3–6 месяцев с SLA на отклик.
Если подрядчик обещает «всё и сразу» за 200 тысяч — это либо шаблонное решение, которое придется дорабатывать за ваш счёт, либо откровенный обман.
Технические риски: что нужно проверить в исходном коде
Даже если подрядчик всё формально сдал, приложение может работать с ошибками через месяц-два. Вот список технических рисков, которые скрываются за красивой презентацией:
- Отсутствие модульной архитектуры — если код написан «кашей» (спагетти-код), добавить новую функцию будет стоить дороже, чем переписать всё с нуля. Проверяйте, использует ли команда Clean Architecture или VIPER.
- Игнорирование автотестов — приложение без unit-тестов (покрытие менее 40%) — это бомба замедленного действия. Каждое обновление будет ломать старую функциональность.
- Плохая работа офлайн — если приложение нагружено запросами к серверу при каждом действии пользователя, подземные паркинги и метро превратят его в бесполезный экран загрузки.
- Слабая оптимизация размера APK/IPA — приложения «для галочки» весят 150–200 МБ из-за неправильного подключения библиотек. Норма — 20–50 МБ для среднего приложения. Это влияет на конверсию установки.
- Игнорирование версионирования API — если подрядчик не предусмотрел обратную совместимость при обновлении серверной части, пользователи со старой версией приложения получат ошибки.
Заключение: чек-лист для принятия решения
Разработка мобильного приложения — это не покупка телевизора в магазине. Вы получаете не продукт, а проект, который требует контроля на каждом этапе.
Перед тем как переводить предоплату, возьмите этот чек-лист и отметьте пункты, которые подтверждены документально (не на словах): наличие прототипа, прописанные сроки, штрафы за просрочку, доступ к репозиторию, гарантийный период не менее 1 месяца, чёткий перечень работ.
Если хотя бы 3 пункта из 6 отсутствуют — остановитесь и ищите другого подрядчика. Экономия в 100–200 тысяч рублей на этапе выбора обернется потерей 500 тысяч и полугода времени. Лучше потратить месяц на поиск адекватной команды, чем год на исправление чужих ошибок.
Добавлено: 12.05.2026
