Заказное мобильное приложение может обойтись в несколько миллионов рублей, а сложный сервис с несколькими ролями и интеграциями — в десятки миллионов. Чтобы определить бюджет своего проекта, нужно понять, какие функции необходимы, что уже есть у бизнеса и какие работы предстоит выполнить с нуля.
Ниже разберём, сколько стоит мобильное приложение разной сложности, опираясь на этапы, почасовые ставки и модель оплаты. Отдельно посмотрим, какие расходы появятся после запуска и может ли ИИ сделать разработку дешевле.
Сколько стоит создать мобильное приложение
Разному бизнесу нужны разные приложения: кому-то достаточно таплинка для записи, а кому-то нужно, чтобы клиент мог выбрать врача и оплатить приём прямо в приложении. Самый простой ориентир для первого планирования бюджета — сложность.
Сложность мобильного приложения — это то, сколько возможностей в нём предусмотрено и насколько трудно их реализовать. Такое разделение помогает примерно сопоставить вашу идею с бюджетом, ещё до подробного расчёта.
Естественно, чем сложнее приложение, тем выше стоимость его разработки.
Приложение | Пример состава | Стоимость | Срок |
Простое приложение или MVP на одной платформе | Авторизация, профиль пользователя, 2-3 основных сценария, типовой дизайн | 1,5-3 млн ₽ | 2-3 месяца |
Приложение для бизнеса под iOS и Android | Каталог, заказы, оплата, админ-панель, интеграция с CRM или учётной системой | 3-8 млн ₽ | 4-6 месяцев |
Сложная платформа | Несколько ролей, взаимосвязанные процессы, высокая нагрузка и отраслевые интеграции | От 8 млн ₽ | От 6 месяцев |
Разбираем подробнее, что влияет на цену разработки мобильного приложения.
От чего зависит стоимость разработки мобильного приложения
Функции и роли пользователей
На цену разработки мобильного приложения влияет не количество экранов. Сравним, например, сценарии за кнопкой «Записаться к врачу»:
- Заявка на запись. Пациент оставляет имя и телефон. Администратор связывается с ним и согласовывает время приёма.
- Запись на свободное время. Пациент выбирает врача и время из актуального расписания. Приложение получает данные из медицинской информационной системы клиники, проверяет доступность выбранного времени и подтверждает запись.
Второй вариант, очевидно, сложнее. Поэтому похожие по виду экраны могут заметно отличаться по стоимости разработки.
Функция | Базовый вариант | Что увеличивает бюджет |
Личный кабинет | Профиль и история действий | Несколько ролей, документы, согласования, кабинеты организаций |
Каталог | Список и карточки товаров | Сложные фильтры, персональные цены, остатки по филиалам |
Оплата | Один способ оплаты заказа | Подписки, возвраты, повторные списания, распределение платежей |
Геолокация | Точки и адреса на карте | Фоновый трекинг, маршрутизация, работа без стабильной связи |
Уведомления | Сообщения о статусах | Сегменты аудитории, персональные сценарии, управление рассылками |
Чат | Подключение готового сервиса | Собственная инфраструктура, вложения, поиск и модерация |
На бюджет влияет и количество ролей пользователей. Если приложение рассчитано только на клиентов, достаточно предусмотреть функции для них. Но если им будут пользоваться ещё специалисты или администраторы, понадобятся дополнительные. Для каждой роли нужно определить, какие данные и действия ей доступны. Всё это увеличивает объём разработки, тестирования и, соответственно, цены.
Серверная часть и интеграции
Под капотом мобильного приложения работает серверная часть: она хранит данные, обрабатывает заказы и платежи, проверяет права доступа и связывает приложение с другими сервисами. Всё это нужно, чтобы пользователь мог работать с приложением.
В бюджете важно учитывать три вида затрат.
Статья затрат | Что в неё входит | Как оплачивается |
Разработка серверной части | Логика работы приложения и хранение данных пользователей | Создание входит в смету разработки. Поддержка и новые функции оплачиваются отдельно |
Интеграции | Обмен данными с внешними системами (например, передача заказа в CRM) | Оплачивается разработка подключения. У самого сервиса может быть свой тариф |
Размещение и инфраструктура | Ресурсы, на которых работает серверная часть приложения | Регулярная плата за размещение и обслуживание |
Если у бизнеса уже есть серверная часть, например, для сайта, её иногда можно использовать и для мобильного приложения. Для этого проверяют, поддерживает ли она нужные функции и есть ли API — интерфейс, через который приложение сможет получать и передавать данные. Если подходящей основы нет, её разработку включают в смету.
Сложность интеграций тоже влияет на цену. Если у сервиса нет понятной инструкции по подключению, разработчикам потребуется больше времени.
Нативность приложения: стоимость разработки приложения для iOS и Android
Если приложение нужно и для iOS, и для Android, выбор платформы влияет на стоимость создания и дальнейших обновлений.
При нативной разработке создают две отдельные версии приложения. Например, функцию записи к врачу разрабатывают для каждой платформы. Если позже понадобится добавить перенос записи, изменения придётся внести в обе версии. При этом серверная часть может быть общей.
При кроссплатформенной разработке значительную часть кода используют совместно (и для iOS, и для Android). Это сокращает повторную работу и может снизить стоимость создания мобильного приложения. Но проверять его всё равно нужно на обеих платформах, а некоторые функции потребуют отдельного кода. Чем больше таких исключений, тем меньше экономия.
Если нужна только одна платформа, в смету включают одну мобильную версию. Поэтому вопросы «сколько стоит разработка приложений для iOS и для Android, или только для для iOS или для Android» решаются одинаково: оценивают функции приложения и работы, необходимые для его запуска.
Дизайн и условия работы приложения
Дизайн — одна из важнейших частей приложения. Должно быть быстро, удобно и красиво. На бюджет влияет то, как именно этого добиться:
- Внешний вид. Из стандартных элементов можно собрать красивый и удобный интерфейс приложения. Но если хочется авторских иллюстраций или необычного оформления, на дизайн потребуется больше ресурсов.
- Работа без интернета. Для работы без интернета нужно продумать, что пользователь сможет делать офлайн и как изменения сохранятся после восстановления связи. Например, что произойдёт, если одну запись за это время отредактируют два человека.
- Количество пользователей. Если приложением будут пользоваться тысячи людей одновременно, серверную часть нужно подготовить к такой нагрузке и проверить, выдержит ли она её.
Обычно проектные требования прорабатывает менеджер проекта. Но, если у вас пока есть только идея или список функций, мы в Aiston поможем разобраться в деталях и подготовить основу для оценки.
Как формируется смета на разработку приложения
Стоимость разработки мобильного приложения обычно уточняют постепенно. Сначала по описанию идеи называют примерную цену. Затем разбирают, как должны работать функции приложения, и готовят более точную смету. Погрузимся в детали.
От предварительной оценки к подробному расчёту
На первом обсуждении приложение можно оценить по аналогии с похожими проектами. Команда сопоставляет функции, платформы, роли и интеграции и называет диапазон с допущениями.
Например, сначала стоимость считают с учётом того, что приложение будет использовать серверную часть сайта. Если выяснится, что она не подходит и нужно разработать новую, бюджет увеличится.
После уточнения требований проект разбивают на работы и оценивают каждую. Для заказчика этот процесс выглядит так:
- Определить первую версию. Записать, кто пользуется приложением и какие действия он должен выполнять. Отделить обязательные сценарии от будущих улучшений.
- Зафиксировать условия. Указать платформы, роли, ожидаемую нагрузку, интеграции и готовые компоненты. Описать ограничения (например, ту же работу без интернета).
- Разложить функции на задачи. Для каждого сценария определить работы по интерфейсу, серверу, обмену данными и проверке.
- Оценить трудозатраты по ролям. Специалисты оценивают часы на реализацию проекта. За основу берут похожие задачи из своего опыта.
- Рассчитать бюджет. Умножить часы на ставки и учесть общие работы, внешние расходы и конкретные риски. Проверить, что ничего не потерялось и не посчитано дважды.
Такой порядок опирается на общие принципы оценки проектов: описание объёма, декомпозицию работ, фиксацию допущений, анализ неопределённости и последующее уточнение расчёта.
Какие работы должны быть учтены
При расчёте часы распределяют по видам работ. В зависимости от проекта в смету могут входить разные этапы разработки.
Работа | Что получает заказчик |
Аналитика и проектирование | Описание требований, сценариев, ролей и интеграций; границы первой версии |
UX/UI-дизайн | Макеты экранов, элементы интерфейса и основные состояния |
Мобильная разработка | Работающее приложение для согласованных платформ |
Сервер и интеграции | Бизнес-логика, хранение данных, API и обмен с внешними системами |
Админ-панель | Инструменты управления продуктом для сотрудников |
Тестирование | Проверка функций, совместимости и обработки ошибок |
Подготовка к релизу | Рабочее окружение, сборки и согласованный объём публикации |
Управление проектом | Координация команды, контроль задач и изменений |
Все эти работы должны быть учтены в цене, но в сметах они могут быть оформлены по-разному. Например, тестирование может стоять отдельной строкой или входить в стоимость разработки. Поэтому при сравнении предложений советуем смотреть на то, что в неё включено.
Почасовые ставки специалистов
Когда состав работ определён, команда оценивает необходимое время. Стоимость каждой задачи рассчитывают по формуле: количество часов × ставка специалиста.
Ставка зависит от специализации и компании. Для ориентира можно посмотреть открытые прайсы студий и агентств. Мы привели усредненные показатели по рынку.
Работа специалиста | Диапазон между двумя опубликованными ставками |
Проектирование | 2 450–3 400 ₽/час |
UX/UI-дизайн | 2 350–3 400 ₽/час |
Программирование мобильного приложения | 2 850–3 500 ₽/час |
Анализ и тестирование | 2 750–3 000 ₽/час |
IT-подрядчик может устанавливать отдельную ставку для каждого специалиста или использовать единую ставку для всей команды.
Покажем расчёт на условном примере.
Работа | Часы | Стоимость при 3 000 ₽/час |
Аналитика и проектирование | 100 | 300 000 ₽ |
Дизайн | 120 | 360 000 ₽ |
Мобильная разработка | 320 | 960 000 ₽ |
Сервер, админ-панель и интеграции | 220 | 660 000 ₽ |
Тестирование | 120 | 360 000 ₽ |
Управление проектом | 80 | 240 000 ₽ |
Подготовка и выпуск релиза | 40 | 120 000 ₽ |
Итого | 1 000 | 3 000 000 ₽ |
В примере 1000 часов при единой ставке 3000 ₽ составляют 3 млн ₽. На программирование мобильной и серверной частей приходится 54% суммы, ещё 46% — на аналитику, дизайн, тестирование, управление и подготовку к запуску. В другом проекте соотношение будет отличаться.
При этом 1000 часов работы команды не равны 1000 часам до запуска. Дизайнеры, разработчики и тестировщики могут работать параллельно, поэтому срок проекта рассчитывают отдельно.
Модели оплаты разработки
После оценки объёма и трудозатрат стороны выбирают модель оплаты. Fixed Price и Time & Materials определяют, как оплачивается работа.
Важно: выше мы рассчитали стоимость проекта через объём работ, часы и ставки специалистов. Этот расчёт нужен при любой модели сотрудничества.
Модель | Как оплачивается работа | Когда подходит | Что контролировать |
Fixed Price — фиксированная цена | Согласованная сумма за определённый объём и результат | Требования понятны и не предполагают частых изменений | Критерии приёмки, исключения и стоимость изменений |
Time & Materials — оплата времени | Фактически выполненные часы по согласованным ставкам и предусмотренные расходы | Требования уточняются в процессе, важна гибкость приоритетов | Отчётность, бюджетный лимит и прогноз оставшихся работ |
Выделенная команда | Оплачивается согласованный состав команды и её загрузка за период | Продукт постоянно развивается и есть устойчивый поток задач | Загрузку специалистов, результаты и условия изменения команды |
Retainer — регулярный пакет работ | Фиксированный платёж за оговорённый объём времени или услуг | Нужны регулярная поддержка и небольшие доработки | Состав пакета, превышение лимита и перенос остатка |
При этом, выделенная команда описывает организацию работы, поэтому её услуги могут оплачиваться по часам или по согласованному месячному бюджету. Содержание retainer тоже зависит от договора.
Для нового продукта возможна комбинация: сначала отдельный этап исследования и проектирования, затем фиксированная оценка понятной первой версии, а после запуска — оплата развития по времени.
Как сравнить предложения разработчиков
Когда понятны состав работ, ставки и модель оплаты, можно сравнивать коммерческие предложения. Начать стоит с одного описания задачи для всех подрядчиков (например, одинаковые платформы и обязательные функции).
Затем свести предложения по основным пунктам.
- Объём продукта: какие сценарии включены и что явно исключено.
- Сервер и админка: используются готовые системы или разрабатываются новые.
- Интеграции: какие данные передаются и кто отвечает за другую сторону обмена.
- Тестирование и запуск: что проверяют, какие работы по публикации включены.
- Управление и изменения: как согласуются новые задачи и пересмотр бюджета.
- Передача результата и сопровождение: код, документация, доступы, гарантийные исправления.
- Итоговая сумма: налоги, внешние сервисы и прочие отдельные платежи.
Если предложение дороже, разберитесь, что вы получаете за эту разницу: более продуманное решение, меньшие риски, сильную экспертизу или лишний объём работ. Если предложение дешевле, проверьте, чем достигнута экономия: более эффективным подходом или исключением важных работ.
Какие расходы появятся после запуска
После релиза приложение продолжает жить: им пользуются люди, а операционные системы и внешние сервисы обновляются. Поэтому при планировании бюджета стоит оценить учесть поддержку и сопровождение.
- Инфраструктура. Приложению нужны серверные ресурсы и место для хранения данных. Расходы будут зависеть от количества пользователей и их активности.
- Поддержка. Разбор инцидентов и обновления. На берегу уточните у команды, какие работы входят в гарантию, а какие оплачиваются отдельно.
- Внешние сервисы. За отправку SMS, использование карт, проверку данных и другие подключённые услуги может взиматься отдельная плата. Часто она растёт вместе с количеством пользователей или операций.
- Развитие. После запуска становится понятнее, какие функции действительно нужны аудитории. Их добавление лучше планировать отдельным бюджетом, не смешивая с исправлением ошибок и поддержанием работы приложения.
Рассмотрим условный бюджет приложения за 3 млн ₽:
Расход | Допущение | За 12 месяцев после релиза |
Поддержка | 40 000 ₽ в месяц | 480 000 ₽ |
Инфраструктура | 15 000 ₽ в месяц | 180 000 ₽ |
Внешние сервисы | 5 000 ₽ в месяц | 60 000 ₽ |
Плановые новые функции | Отдельный годовой бюджет | 600 000 ₽ |
Всего после запуска | 1 320 000 ₽ |
В этом примере разработка и первый год работы приложения обойдутся в 4,32 млн ₽. Продвижение и подготовка контента в расчёт не входят — их бюджет зависит от задач бизнеса. При сравнении предложений также проверьте, указаны ли цены с НДС.
Как сократить бюджет приложения
Чтобы сократить бюджет, нужно считать по смете. Команда сравнивает два варианта и определяет, какие работы и расходы исчезнут или появятся после изменения решения.
Экономия = стоимость исходного варианта − стоимость упрощённого варианта |
Например, разработка собственного чата занимает 200 часов, а подключение готового сервиса — 40 часов. При ставке 3000 ₽ разница составит 480 тыс. ₽. Если интеграция и первый год использования сервиса обойдутся в 120 тыс. ₽, фактическая экономия составит 360 тыс. ₽: (200 − 40) × 3 000 − 120 000 = 360 000 ₽
По такому же принципу оценивают остальное: из исходной сметы убирают ненужные работы и добавляют стоимость выбранного решения и сравнивают результаты. При этом учитывают как разработку, так и будущие платежи за инфраструктуру и поддержку.
Для своего приложения процент рассчитывают после сравнения вариантов:
Экономия, % = экономия ÷ стоимость исходного варианта × 100% |
Снизить стартовый бюджет обычно помогает сокращение первой версии (MVP), использование подходящих готовых решений и отказ от лишней платформы. Но более дешёвый вариант стоит оценивать вместе с будущими расходами и ограничениями.
Становится ли разработка мобильного приложения дешевле благодаря ИИ
Короткий ответ: ИИ может снизить стоимость разработки, если помогает команде выполнить тот же объём работы быстрее. Но само по себе использование ИИ не означает, что приложение станет дешевле.
ИИ помогает разработчикам быстрее писать типовой код и разбираться с рутинными задачами. Результат всё равно нужно проверить и встроить в продукт. Поэтому значение имеет не наличие ИИ-инструмента, а то, сколько рабочих часов он действительно сэкономил.
Данные исследований различаются. В исследовании Management Science, охватившем 4 867 разработчиков, ИИ-помощник увеличил количество выполненных задач в среднем на 26,08%. В эксперименте METR опытные разработчики, напротив, потратили с ИИ на 19% больше времени. Они работали в знакомых крупных проектах, а инструменты иногда предлагали решения, которые приходилось исправлять.
Даже заметное ускорение не переносится на весь бюджет. Допустим, ИИ применяется в работах, которые составляют 40% сметы, и сокращает их трудоёмкость на 30%. Тогда потенциальная экономия всего проекта составит 12%: 40% × 30% = 12%
Из этой суммы нужно вычесть стоимость ИИ-инструментов и время на проверку результата. Это условный пример, который показывает главное: ускорение отдельных задач на 30% не означает, что всё приложение подешевеет на 30%.
При оплате по Time & Materials уменьшение количества часов может снизить итоговый счёт. При Fixed Price стоимость согласуют заранее, поэтому повышение скорости работы команды не обязательно изменит цену для заказчика.
Если же ИИ должен стать функцией самого приложения, бюджет обычно увеличивается. Например, для помощника по документам нужно подключить модель и настроить работу с данными. После запуска также появятся расходы на использование модели.
Таким образом, ИИ как рабочий инструмент команды может сократить трудозатраты. ИИ внутри приложения — это новая функция, которую нужно отдельно разработать и оплачивать.
Мобильное приложение для сложных задач
Мы в Aiston разрабатываем сложные приложения для корпоративного контура — с несколькими ролями, интеграциями, нестандартной логикой и фокусом на безопасность. Расскажите нам о задаче, даже если пока она сформулирована только в общих чертах. Мы рассчитаем стоимость создания мобильного приложения и предложим состав первой версии под задачи вашего бизнеса.
А ещё — посмотрите наши кейсы, чтобы узнать, как мы решаем похожие задачи. А за новыми материалами о разработке и цифровых продуктах приходите в наш Telegram-канал.