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

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

Диапазоны цен: что почём на рынке

Если убрать маркетинговые формулировки, реальные вилки по России выглядят так:

• UI/UX-дизайн приложения (прототип и макеты 5–10 экранов) — от 8 000 до 60 000 ₽ в зависимости от студии и глубины проработки.
• MVP на одну платформу (Android или iOS, базовая логика, авторизация, одна ключевая функция) — от 20 000 до 150 000 ₽.
• Кроссплатформенное приложение (iOS + Android из одной кодовой базы, Flutter или React Native) — от 35 000 до 400 000 ₽.
• Приложение «под ключ» с личными кабинетами, оплатой, интеграциями с CRM или 1С, админ-панелью и публикацией во всех сторах — от 70 000 до 1,5–3 млн ₽ и выше.
• Два нативных приложения (Swift для iOS + Kotlin для Android отдельными командами) — обычно на 30–60% дороже кроссплатформенного решения при сопоставимом функционале.

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

Три составляющие цены — и почему они неравноценны

Любой проект раскладывается на три блока: дизайн, клиентская разработка (то, что видит пользователь на экране) и серверная часть с интеграциями (то, что происходит «за кулисами»). На практике доля дизайна в общем бюджете редко превышает 10–15%, даже у продуктов с проработанной визуальной айдентикой. Основные деньги уходят на вторую и третью части — и именно третья, серверная логика, чаще всего оказывается недооценённой на этапе первого разговора с заказчиком.

Логика простая: экран «Каталог» нарисовать один раз — работа дизайнера на пару дней. А заставить этот каталог показывать актуальные остатки, применять скидки для конкретного пользователя, синхронизироваться с 1С и не «падать» при 500 одновременных запросах — это уже архитектура базы данных, API, очереди задач и тестирование под нагрузкой. Красивый интерфейс без этой логики — просто набор картинок.

Почему не дизайн решает бюджет

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

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

Что конкретно поднимает бюджет

По нашему опыту, смета вырастает в разы именно из-за следующих пунктов — независимо от того, насколько простым выглядел исходный список экранов:

• Онлайн-оплата и расчёты. Подключение платёжного шлюза — от 5 000 ₽ за саму интеграцию, но если нужны рассрочка, возвраты, сплит-платежи между несколькими получателями или чеки для налоговой — бюджет и сроки увеличиваются кратно.
• Интеграция с CRM, 1С или складской системой. Каждая связка — это отдельный протокол обмена, отдельное тестирование и обработка ошибок при сбоях связи. Одна интеграция — от 5 000 ₽, но на практике их редко бывает меньше двух-трёх.
• Личные кабинеты, роли и авторизация. Разграничение прав между продавцом, покупателем и администратором превращает простое приложение в систему с несколькими интерфейсами внутри одного продукта.
• Push-уведомления и реальное время. Статусы заказа, чаты, геолокация курьера на карте — всё это требует постоянного соединения с сервером и отдельной инфраструктуры, а не просто «отправить уведомление».
• Админ-панель. Кто-то должен управлять контентом, заказами и пользователями без обращения к разработчику каждый раз — это фактически второе приложение, только для сотрудников, а не для клиентов.
• Нагрузка и масштаб. Приложение для 200 постоянных клиентов и приложение, рассчитанное на всплеск в 10 000 установок за неделю после рекламной кампании, — разные по архитектуре задачи, даже если экраны выглядят одинаково.

Обратите внимание: ни один из этих пунктов не связан с тем, насколько красиво выглядит кнопка «Купить». Все они — про то, что происходит после нажатия.

Нативная разработка против кроссплатформенной

Отдельный вопрос бюджета — писать ли два нативных приложения (отдельно под iOS и под Android) или одно кроссплатформенное на общей кодовой базе. Для подавляющего большинства бизнес-задач — магазины, доставка, записи на услуги, внутренние приложения для сотрудников — кроссплатформенная разработка на Flutter или React Native закрывает потребность полностью: пользователь не заметит разницы, а экономия на разработке и последующей поддержке составляет 30–40%, потому что правки вносятся один раз, а не дважды.

Нативная разработка оправдана в узком круге случаев: приложения с интенсивной 3D-графикой или AR, продукты, где счёт идёт на миллисекунды отклика (например, финансовый трейдинг), либо глубокая работа с возможностями конкретной платформы, которых нет в кроссплатформенных фреймворках. Если вам предлагают писать нативно «для надёжности» под задачу вроде каталога товаров или записи к мастеру — это, скорее всего, не про качество, а про удвоение чека.

Как спланировать бюджет и не переплатить

Рабочая стратегия для малого и среднего бизнеса — не пытаться сразу собрать финальную версию продукта, а начать с MVP: минимально жизнеспособного приложения с одной ключевой функцией. Это не «урезанная» версия ради экономии, а способ проверить, что продукт вообще нужен пользователям, прежде чем вкладываться в полный набор интеграций и ролей. MVP на iOS и Android с базовой авторизацией и одной центральной функцией укладывается в диапазон 35 000–150 000 ₽ и 3–4 недели, тогда как попытка сразу заказать «как у Wildberries» рискует превратиться в проект на 6–12 месяцев без гарантии, что аудитория вообще откликнется.

Второй способ сэкономить осмысленно — заранее считать не только разработку, но и то, что будет после запуска. Приложения без сопровождения быстро ломаются: сторы меняют требования к API, новые версии iOS и Android меняют поведение системных компонентов, а без обновлений приложение через несколько месяцев может просто перестать устанавливаться. Закладывайте в бюджет 5–10% от стоимости разработки на ежемесячную поддержку — это дешевле, чем полная переработка через год.

Практический вывод

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

Если задача укладывается в понятный сценарий — каталог, запись, личный кабинет с оплатой — ориентируйтесь на MVP-диапазон 35 000–150 000 ₽ и кроссплатформенную разработку: это самый быстрый способ проверить продукт на реальных пользователях. Если же в задаче с первого дня заложены несколько ролей, расчёты между сторонами и синхронизация с внутренними системами компании, закладывайте бюджет от 150 000 ₽ и выше и планируйте проект поэтапно — так серверная логика и интеграции, которые определяют реальную стоимость, будут спроектированы до начала кодирования, а не переделаны после.