Каждый клиент, который приходит к нам с идеей мобильного приложения, задаёт примерно одни и те же пять вопросов. Сколько это стоит? Сколько времени займёт? Делать на iOS, Android или сразу везде? Можно ли без бэкенда? И главное — стоит ли вообще делать?

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

Мы в ItDigital.pro делаем мобильные приложения уже больше восьми лет — на iOS, Android, кроссплатформенные. Видели всё: успешные истории и проекты, которые лучше было не начинать. Этим опытом и поделимся.

Типы мобильных приложений

Прежде чем считать стоимость, нужно понять, какой именно тип приложения вам подходит. Это не просто технический вопрос — он влияет на бюджет в 2-3 раза.

Native (нативная разработка)

Приложения, написанные специально под iOS (на Swift) или под Android (на Kotlin) с использованием родных инструментов разработки. Каждая платформа — отдельная разработка.

Плюсы. Максимальная производительность — нативные приложения работают плавно, без лагов даже на старых устройствах. Полный доступ ко всем функциям смартфона: камера, NFC, геолокация, push-уведомления, биометрия. Идеальный UX, привычный для пользователей платформы. Лучшее качество анимаций и переходов.

Минусы. Самый дорогой вариант — нужно делать два приложения вместо одного. Удвоенные сроки разработки и поддержки. Команда должна состоять минимум из двух разработчиков (отдельно iOS и Android).

Когда выбирать. Если приложение — это сердце бизнеса (банк, такси, доставка). Если важна максимальная производительность (игры, видео-приложения, AR). Если планируется долгая жизнь продукта с регулярными обновлениями. Если бюджет позволяет — нативная разработка всегда даёт лучший результат.

Подробнее о наших проектах — на страницах разработки приложений iOS и разработки приложений Android.

Кроссплатформенные приложения

Один код пишется один раз и собирается в две версии — для iOS и Android. Главные технологии в 2025 году — Flutter (от Google) и React Native (от Meta).

Flutter — флагман кросс-платформенной разработки. Высокая производительность, близкая к нативной. Гибкость в дизайне. Растущее сообщество. Используется в Alibaba, BMW, eBay, многих банковских приложениях.

React Native — старый игрок рынка. Используется в Facebook, Instagram, Discord, Tesla. Меньше гибкости в кастомизации, но огромная экосистема готовых компонентов.

Плюсы. Экономия 30-50% бюджета и сроков по сравнению с native. Один разработчик может вести оба приложения. Быстрые обновления (правка кода идёт сразу в обе платформы).

Минусы. Производительность ниже, чем у native (для большинства задач незаметно, но в сложных интерфейсах разница есть). Часть редких функций приходится дописывать нативно. Зависимость от технологии: если фреймворк перестанет развиваться (как Cordova или Xamarin), проект придётся переписывать.

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

PWA — прогрессивные веб-приложения

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

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

Минусы. Ограниченный функционал — нет доступа ко многим возможностям телефона. На iOS поддержка PWA сильно ограничена (Apple намеренно тормозит развитие технологии, потому что она конкурирует с App Store). Хуже работа с офлайном и оффлайн-данными.

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

Гибридные приложения

Старый подход, который частично себя изжил. Это веб-приложение, обёрнутое в нативный «контейнер» (через Cordova, Ionic). Дешевле native, но качество и производительность хуже, чем у современных кроссплатформенных решений на Flutter или React Native.

В 2025 году новые проекты на гибридах почти не делают — кросс-платформенные фреймворки дают практически то же самое, только с лучшим качеством. Гибридные приложения остались в основном в виде уже работающих legacy-проектов.

Сравнительная таблица типов

Параметр	Native	Кроссплатформа (Flutter, RN)	PWA
Стоимость	от 1 500 000 ₽	от 800 000 ₽	от 300 000 ₽
Срок разработки	4-12 месяцев	3-8 месяцев	1-3 месяца
Производительность	Максимальная	Высокая	Средняя
Доступ к функциям телефона	Полный	Расширенный	Ограниченный
Публикация в App Store / Google Play	Да	Да	Нет (отдельные обходные пути)
Комиссия магазинов с покупок	15-30%	15-30%	0%
Сложность поддержки	Высокая (2 кодовые базы)	Средняя	Низкая
Под какие задачи	Топ-продукты, игры, банки	Большинство бизнес-задач	Простые сервисы, MVP

7 этапов разработки приложения

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

Этап 1 — Аналитика и прототипирование

Самый недооценённый этап. Каждая неделя, вложенная в аналитику на старте, экономит месяц переделок потом.

Что происходит. Глубокое погружение в бизнес клиента: зачем нужно приложение, кто пользователи, какие задачи оно решает, какие конкурентные продукты есть на рынке. Определение MVP — минимально жизнеспособного продукта, с которым можно выйти на пользователей. Прорисовка пользовательских сценариев (user flows): как именно человек будет пользоваться приложением. Создание прототипов — упрощённых схем экранов в Figma или Miro, без визуала, только для проверки логики.

Сроки: 2-4 недели для среднего проекта. Стоимость: 50 000-200 000 рублей.

Что получает клиент. Документ с описанием концепции продукта. Спецификацию основных функций. Прототип в Figma, который можно «потыкать» как готовое приложение и понять, как всё будет работать. Оценку стоимости и сроков остальных этапов.

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

Этап 2 — UX/UI дизайн

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

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

UI-часть: цветовая схема, шрифты, иконки, иллюстрации, общая визуальная подача. Соответствие гайдлайнам платформы (Material Design для Android, Human Interface Guidelines для iOS) или собственному стилю компании.

Сроки: 3-8 недель. Стоимость: 100 000-500 000 рублей, в зависимости от количества экранов и сложности интерфейса. Подробнее о подходе — на странице дизайна приложения.

Хороший дизайнер мобильного приложения — это не «красивый художник», а человек, который понимает, как пользователи взаимодействуют с интерфейсом. Он знает, что палец закрывает нижнюю треть экрана, что текст меньше 16px на мобильных читать сложно, что в iOS и Android разные паттерны навигации.

Особенности дизайна для iOS vs Android

Одна из частых ошибок начинающих заказчиков — желание «сделать одинаково для обеих платформ». На самом деле iOS и Android — это разные миры со своими привычками пользователей, и слепое копирование вредит.

На iOS навигация обычно через нижний таб-бар, кнопка возврата в левом верхнем углу или свайп с края экрана. На Android — нижний таб-бар или боковое выдвижное меню (drawer), кнопка возврата системная (внизу экрана или жестом). Иконки, шрифты, отступы тоже различаются.

Хорошая практика — делать единый бренд и общую логику, но адаптировать конкретные элементы под платформу. Пользователи iPhone и пользователи Android-телефонов чаще всего не пересекаются, и им комфортнее работать с привычными для своей системы паттернами.

Дизайн-система и компоненты

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

Готовые системы — Material Design (Google) для Android и Human Interface Guidelines (Apple) для iOS — это базис, на котором строятся свои стили. Не стоит изобретать с нуля то, что уже годами вылизано миллионами пользователей.

Этап 3 — Backend-разработка

Сервер, базы данных, API — всё то, что обеспечивает работу приложения «за кадром». Авторизация пользователей, хранение данных, обработка платежей, push-уведомления, аналитика.

Чем сложнее приложение, тем больше веса у бэкенда. Простой каталог с информацией — минимальный бэкенд. Социальная сеть с сообщениями, лентой, рекомендациями — мощный бэкенд, иногда 60-70% всех трудозатрат проекта.

Технологии. Для большинства приложений — Node.js, Python (Django, FastAPI), Ruby on Rails, PHP (Laravel), Go. Базы данных: PostgreSQL, MongoDB, MySQL. Облачная инфраструктура: AWS, Google Cloud, Yandex Cloud, Selectel.

Сроки: 2-6 месяцев параллельно с фронтенд-разработкой. Стоимость: от 200 000 рублей для простого MVP до миллионов для сложных платформ. Подробнее — на странице бэкенд-разработки.

Этап 4 — Mobile-разработка

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

Для native разработка идёт параллельно: один разработчик пишет iOS, другой Android. Для кроссплатформенных — один код пишется один раз.

Сроки: 3-8 месяцев в зависимости от сложности. Стоимость: 500 000-3 000 000 рублей.

Этап 5 — Тестирование и QA

Этап, который пытаются «срезать» все недобросовестные подрядчики. И именно на нём сайт превращается из «работает на компьютере у разработчика» в «работает у реального пользователя».

Что тестируется. Функциональное тестирование — все ли кнопки работают, все ли сценарии проходят. Тестирование на разных устройствах — приложение должно работать на 200+ моделях телефонов с разными размерами экранов, версиями ОС, особенностями. Тестирование производительности — не зависает ли на старых телефонах, не разряжает ли быстро батарею. Тестирование под нагрузкой — что будет, если 10 000 пользователей зайдут одновременно. Тестирование безопасности — нет ли уязвимостей в API, защищены ли пользовательские данные.

Сроки: 2-6 недель. В качестве выделенного этапа в конце разработки, плюс непрерывное тестирование в процессе. Стоимость: 10-20% от бюджета разработки.

Этап 6 — Публикация в App Store и Google Play

Готовое приложение нужно загрузить в магазины приложений. У каждого свои правила, и не каждое приложение проходит модерацию с первого раза.

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

Модерация. Google Play обычно одобряет приложения за 1-3 дня. Apple — от 1 дня до 2 недель, с большей вероятностью отказа. Типичные причины отказа: непрозрачные функции, нарушение правил по работе с пользовательскими данными, несоответствие гайдлайнам интерфейса, копирование чужого функционала.

Для российских разработчиков в 2025 году отдельная сложность — публикация в App Store. Из-за ограничений нужны зарубежные банковские реквизиты для оплаты годового взноса Apple (99 долларов), нужен заграничный аккаунт разработчика. У Google ситуация проще, но тоже есть нюансы.

Альтернативные магазины: RuStore — российский магазин приложений, набирает обороты. Huawei AppGallery — для пользователей телефонов Huawei. Прямая раздача APK с сайта — для Android.

ASO — оптимизация в магазинах приложений

Аналог SEO, только для App Store и Google Play. Магазины приложений — это поисковики, и попадание в топ выдачи по своим запросам напрямую влияет на установки.

Основные элементы ASO. Название приложения (с ключевыми словами). Описание (длинное и короткое, с правильной плотностью ключей). Скриншоты (4-6 первых — самые важные, их видит пользователь до клика на «подробнее»). Видео-превью (увеличивает конверсию в установки на 20-30%). Иконка (узнаваемость и контрастность). Категория и теги. Отзывы и рейтинг.

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

Этап 7 — Поддержка и обновления

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

Что входит в поддержку. Исправление багов, которые всплывают у реальных пользователей. Адаптация под новые версии iOS и Android (выходят раз в год, могут сломать часть функций). Обновление сторонних библиотек и зависимостей. Развитие функционала — новые фичи, улучшения. Работа с отзывами и службой поддержки. Мониторинг производительности и серверов.

Стоимость поддержки: обычно 15-30% от бюджета разработки в год. Для приложения на 2 000 000 это 300 000-600 000 в год на поддержку.

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

Сроки разработки — реалистичные ожидания

Самый болезненный разговор с клиентами. Все хотят получить приложение «за месяц-полтора». Реальность совсем другая.

MVP — от 2 до 4 месяцев

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

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

Срок: 2-4 месяца. Бюджет: 800 000-2 500 000 рублей. Команда: 3-5 человек.

Зачем нужен MVP. Чтобы быстрее проверить гипотезу на реальных пользователях. Если идея не работает, лучше понять это, потратив 2 миллиона за 3 месяца, чем 10 миллионов за год.

Полноценное приложение — от 4 до 12 месяцев

Когда MVP подтвердил гипотезу и нужно строить полноценный продукт со всеми функциями.

Срок: 6-12 месяцев для большинства бизнес-приложений. Бюджет: 2 500 000-10 000 000 рублей. Команда: 5-12 человек.

Это всё ещё реалистичные цифры, не для топ-1 в App Store, а для нормального коммерческого приложения с конкурентным функционалом.

Сложные продукты — от 12 месяцев

Социальные сети, маркетплейсы, банковские приложения, сложные SaaS-продукты. Здесь сроки уходят за год, бюджеты — за десятки миллионов.

Команда — 15-30 человек. Команды у компаний типа Тинькофф, Сбер, Озон, Wildberries в продуктовой разработке мобильных приложений ещё больше.

Почему «за месяц» — это красный флаг

Если подрядчик обещает разработать мобильное приложение за месяц-полтора, это значит одно из трёх. Первое — это конструктор приложений, генерирующий шаблонный продукт без индивидуальной разработки (типа AppMaster, Glide). Качество таких приложений невысокое, гибкость минимальная. Второе — подрядчик демпингует и собирает клиентов на конвейерной разработке, по факту делая каждое приложение «как все, только перекрасили». Третье — подрядчик никогда не сдавал свои проекты в срок и просто врёт на этапе продажи.

Реалистичный минимум для полностью индивидуальной разработки даже простого приложения — 2-3 месяца. За меньшее время невозможно нормально сделать аналитику, дизайн, разработку, тестирование, публикацию. Что-то будет сделано откровенно плохо.

Сколько стоит разработка мобильного приложения в России

Цены в 2025 году в Москве и Санкт-Петербурге у студий среднего и выше среднего уровня.

Тип приложения	Минимум	Средний рынок	Премиум
PWA-приложение	300 000 ₽	500 000-1 000 000 ₽	1 500 000 ₽+
MVP на Flutter/RN	800 000 ₽	1 500 000-2 500 000 ₽	3 500 000 ₽+
MVP native (iOS + Android)	1 500 000 ₽	3 000 000-5 000 000 ₽	7 000 000 ₽+
Полная версия Flutter/RN	2 000 000 ₽	4 000 000-8 000 000 ₽	12 000 000 ₽+
Полная версия native	4 000 000 ₽	8 000 000-15 000 000 ₽	25 000 000 ₽+
Сложный продукт (маркетплейс, соцсеть)	от 5 000 000 ₽	15 000 000-30 000 000 ₽	от 50 000 000 ₽

Почему цены так сильно варьируются

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

Сложность дизайна. Шаблонный дизайн с типовыми компонентами — быстрее и дешевле. Уникальный дизайн с авторскими иллюстрациями, анимациями, нестандартными переходами — дороже в 2-3 раза.

Количество экранов и функций. Приложение из 10 экранов с базовым функционалом — это один объём работы. Приложение из 80 экранов с разной логикой для разных типов пользователей — совсем другой.

Интеграции. Каждая интеграция со сторонним сервисом — это дополнительная работа. Платёжные системы, CRM, ERP, аналитика, маркетинг, push-сервисы, аутентификация через социальные сети — каждая занимает от нескольких дней до нескольких недель.

Уровень команды. Junior-разработчик стоит 50 000 в месяц, middle — 150 000-250 000, senior — 350 000-600 000. Команда из мидлов и сеньоров делает в 2-3 раза быстрее джуниоров и с меньшим количеством ошибок. Но и проект стоит соответственно.

Размер студии. Маленькое агентство из 5-10 человек берёт меньше, чем крупный системный интегратор с офисом в Москве, юристами, бухгалтерией и менеджментом. На итоговую стоимость накладывается «overhead» — расходы студии на инфраструктуру.

Время реакции и поддержка. Студия с SLA «ответ на критичные баги за 2 часа» дороже студии, где «ответим в течение недели». Это разные модели работы.

Как зарабатывать на мобильном приложении

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

Основные модели монетизации

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

Freemium. Бесплатное приложение с платными функциями. Базовая версия даётся даром, расширенные возможности (продвинутые функции, отсутствие рекламы, увеличенные лимиты) — за деньги. Очень распространённая модель: Spotify, Notion, Telegram Premium.

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

Реклама. Показ рекламы внутри приложения. Сети для монетизации: Yandex AppMetrica, Google AdMob, MyTarget. Реальный доход с одного пользователя в месяц обычно 5-50 рублей в зависимости от страны и тематики. Чтобы зарабатывать значимо, нужны сотни тысяч активных пользователей.

Транзакционная модель. Приложение — это магазин или сервис, где пользователь платит за товары или услуги. Доставка, такси, маркетплейсы. Это не «монетизация приложения», это бизнес-модель, где приложение — инструмент.

Комиссия с продаж. Маркетплейсы, агрегаторы, биржи услуг — берут процент с каждой транзакции между сторонами.

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

Комиссия Apple и Google

Важный нюанс. Apple и Google берут комиссию с продаж внутри приложений: 30% от стандартного тарифа, 15% для подписок старше года и для малого бизнеса с оборотом до 1 миллиона долларов. Это значимо влияет на экономику.

Способы обойти комиссию ограничены. Apple запрещает в большинстве категорий приложений направлять пользователя на внешний сайт для оплаты, минуя App Store. Google чуть лояльнее. Транзакционные приложения (доставка, такси) могут принимать оплату напрямую — комиссия не берётся.

Аналитика и метрики

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

Yandex AppMetrica — бесплатный сервис аналитики, аналог Google Analytics для мобильных. Хорошо работает с российскими приложениями.

Firebase Analytics — от Google, де-факто стандарт. Бесплатно для большинства задач.

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

Ключевые метрики для мобильных приложений. DAU/MAU — Daily/Monthly Active Users, активная аудитория. Retention — процент возврата пользователей через день, неделю, месяц после установки. Здоровый D1 retention — 30%+, D7 — 15%+, D30 — 7%+. ARPU/ARPPU — средний доход на пользователя/платящего пользователя. CAC — стоимость привлечения. LTV — пожизненная ценность пользователя.

Как правильно составить ТЗ на приложение

Главный документ проекта, по которому будут оценивать стоимость и сроки. От качества ТЗ зависит, попадёте ли вы в смету или будете доплачивать каждые две недели за «то, что не учли».

Что должно быть в ТЗ

Описание бизнеса и цели приложения. Зачем оно нужно, какие проблемы решает, какие KPI должно достигать.

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

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

Функционал. Подробное описание каждой функции с пользовательскими сценариями. Не «нужна корзина», а «пользователь добавляет товары в корзину, может изменять количество, удалять позиции, видит сумму и стоимость доставки, переходит к оформлению, выбирает способ доставки и оплаты, оформляет заказ, получает подтверждение».

Дизайн-требования. Стиль, фирменные цвета, шрифты, референсы (примеры приложений, которые вам нравятся).

Технические требования. Минимальные версии iOS и Android. Поддерживаемые устройства. Языки. Требования к скорости и надёжности.

Интеграции. Полный список сторонних сервисов: платёжные системы, CRM, аналитика, push-сервисы.

Что НЕ входит в проект. Прямое указание того, чего вы не ждёте. Это снимает массу спорных ситуаций.

Если ТЗ не получается составить самому

Это нормальная ситуация. Большинство клиентов не знают, как правильно описать всё, что нужно. Хорошие студии помогают с составлением ТЗ как отдельным этапом — обычно 50 000-200 000 рублей в зависимости от сложности проекта. Эти деньги многократно окупаются на этапе разработки, когда не приходится переделывать.

На что обратить внимание при выборе подрядчика

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

Портфолио из работающих приложений

Не «у нас 200 кейсов на сайте», а конкретно: вот ссылка в App Store и Google Play на приложение, сделанное этой студией. Скачайте, попользуйтесь, проверьте, как работает. Желательно — в той же категории, что планируете заказывать.

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

Команда и её квалификация

Узнайте, кто конкретно будет работать над вашим проектом. Имена, опыт, прошлые проекты. У хорошей студии разработчики не «безымянные ресурсы», а конкретные люди с историей.

Хороший знак — наличие у разработчиков аккаунтов на GitHub, профилей на Хабре или vc.ru, выступлений на конференциях. Это значит, что они активны в индустрии, развиваются, не сидят в вакууме.

Процесс работы

Спросите, как будет построена работа. Хороший процесс выглядит так. Регулярные демонстрации промежуточных результатов (раз в 1-2 недели). Понятная декомпозиция проекта на этапы с дедлайнами и оплатами. Доступ клиента к системе управления задачами (Jira, Asana, Trello). Регулярные созвоны по статусу проекта. Прозрачное отслеживание прогресса.

Плохо — когда подрядчик говорит «всё сами сделаем, не волнуйтесь, приходите через полгода смотреть результат». В таком режиме шанс получить совсем не то, что вы хотели, близок к 100%.

Договор и юридическая защита

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

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

Цена «выше рынка» как сигнал

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

Аналогично с подозрительно низкими ценами. Если стандартная цена 3 миллиона, а кто-то готов сделать за 500 тысяч — где-то экономия, которая всплывёт потом.

Чек-лист вопросов перед подписанием договора

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

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

Типичные ошибки при заказе мобильного приложения

Десять самых частых ошибок, которые мы наблюдали в работе с клиентами. Большинство — повторяющиеся.

Делать приложение, потому что «у всех есть». Это не аргумент. Мобильное приложение — это инструмент решения конкретной задачи. Если задачи нет, приложение не нужно. Часто хороший адаптивный сайт справляется не хуже, а стоит в 10 раз дешевле.

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

Экономить на дизайнере. Дизайн мобильного приложения — это не «нарисовать иконки». Это продуктовая работа с пониманием поведения пользователей. Экономия на дизайне даёт приложение, которое работает, но никто не хочет им пользоваться.

Игнорировать тестирование. «У нас всё хорошо работает на моём телефоне, значит готово». А пользователь открывает приложение на старом Android — и оно крашится. Минимум 2-4 недели тестирования на различных устройствах — обязательная часть.

Не учитывать стоимость поддержки. Разработка — это 60-70% жизненного цикла бюджета. Остальные 30-40% — поддержка. Если в плане только разработка, через год приложение начнёт ломаться и терять пользователей.

Соглашаться на нереальные сроки. «Сделайте за месяц, мы запускаем рекламу». Подрядчик соглашается, но потом срывает сроки. Лучше реальный срок 3-4 месяца с гарантированным результатом, чем «за месяц» с разочарованием.

Не вкладываться в маркетинг. Сделать приложение и ждать пользователей самотёком — путь в ничто. В App Store и Google Play миллионы приложений, без активного маркетинга вас никто не найдёт.

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

Делать «универсальное» приложение для всех. Когда пытаются угодить и B2B-клиентам, и B2C-пользователям, и партнёрам — получают приложение, в котором плохо работают все три сегмента. Лучше делать отдельные приложения под разные аудитории.

Выбирать подрядчика только по цене. Самый дешёвый вариант почти никогда не оказывается самым выгодным. Сэкономленные при разработке 500 тысяч превращаются в 2 миллиона переделок и потерянных возможностей.

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

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

Менеджер проекта (PM). Связь между клиентом и командой. Планирует работу, отслеживает прогресс, ведёт документацию, организует созвоны и демонстрации. Стоимость в проекте — 10-15% бюджета.

Системный аналитик / Product Owner. Разбирается с требованиями, помогает клиенту сформулировать ТЗ, прорабатывает пользовательские сценарии, описывает функционал для разработчиков. На небольших проектах эту роль может выполнять PM.

UX/UI-дизайнер. Создаёт прототипы и финальные макеты. На больших проектах разделяется на UX-дизайнера (логика) и UI-дизайнера (визуал).

Mobile-разработчики. Минимум один — для кроссплатформенной разработки. Два — для native iOS + Android. На крупных проектах команда из 4-8 разработчиков.

Backend-разработчики. Делают серверную часть. Один-три человека в зависимости от сложности.

QA-инженер (тестировщик). Проверяет работоспособность на разных устройствах, ищет баги, документирует. Минимум один на проект.

DevOps-инженер. Настраивает серверы, CI/CD, мониторинг. Подключается на стадии запуска и поддержки. Может быть штатным или приходящим консультантом.

Итого минимальная команда — 4-5 человек, средняя — 6-10, для крупных проектов — 15+.

Кейсы ItDigital.pro

Несколько примеров наших работ в мобильной разработке.

IT-платформа Dilerio. Корпоративная система автоматизации работы с дилерами. Веб-платформа и нативные мобильные приложения для iOS и Android. Разные пользовательские роли (менеджеры, дилеры, администраторы), отчёты, мониторинг продаж, документооборот. Команда из 8 человек, около 8 месяцев работы.

Приложение для агрегатора услуг. Кросс-платформенное приложение на Flutter с системой исполнителей и заказчиков, чатом, рейтингами, платежами через эквайринг и СБП. Около 5 месяцев работы, команда 5 человек.

B2B-приложение для производственной компании. Личный кабинет дилера с каталогом продукции, оформлением заказов, мониторингом отгрузок и взаиморасчётов. Интеграция с корпоративной ERP-системой. 4 месяца, команда 4 человека.

Больше работ с подробным описанием задач и решений — в разделе кейсов.

Что в итоге

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

Главное на старте — честно ответить на вопрос: вам действительно нужно приложение? Иногда хороший адаптивный сайт справляется лучше и стоит в 5-10 раз дешевле. Иногда — нет, и без приложения бизнес проигрывает конкурентам. Часто разумный путь — начать с PWA или MVP на кроссплатформенной технологии, проверить гипотезу на реальных пользователях, и только потом инвестировать в полноценную native-разработку.

Если ответ «да», и нужно адекватно оценить проект, поговорите с нами. В ItDigital.pro мы делаем мобильные приложения с 2017 года, прошли все типы проектов от MVP до сложных платформ. Обсудить разработку вашего приложения можно через форму брифа — расскажете об идее, мы оценим реалистичные сроки и бюджет, покажем, где можно сэкономить без потери качества, а где экономия обернётся проблемами.