Если нужен ответ в одну строку: стоимость = часы работы всех специалистов × их ставки + инфраструктура и сервисы + поддержка после релиза. Оценки одного и того же «приложения для записи клиентов» у разных исполнителей могут отличаться в несколько раз не потому, что кто-то обманывает, а потому что каждый представил себе свой продукт: с разным числом экранов, ролей, интеграций и глубиной тестирования. Поэтому сравнивать предложения имеет смысл только после того, как у вас есть описание функций — хотя бы на уровне списка сценариев.
Мы сознательно не приводим «средние цены по рынку» в рублях: ставки команд сильно зависят от региона, опыта и формы работы, быстро меняются и без описания проекта мало что значат. Ниже — метод, которым можно получить собственную обоснованную оценку и проверить чужую.
Из чего складывается цена
Бюджет проекта удобно разложить на пять блоков. Разработка клиентского приложения обычно самый заметный, но редко единственный крупный пункт.
| Блок | Что входит | Когда растёт |
|---|---|---|
| Аналитика и дизайн | Исследование, требования, прототип, макеты, UI-кит | Много ролей, нестандартный интерфейс, анимации, отдельный дизайн для планшетов |
| Мобильная разработка | Экраны, логика, работа с устройством (камера, геолокация, push), офлайн-режим | Две нативные платформы, сложные формы, работа без сети, видео и карты |
| Серверная часть и админка | API, база данных, авторизация, панель управления, интеграции | Интеграции с 1С, CRM, платёжными и логистическими сервисами, сложные права доступа |
| Тестирование и управление | QA, тест на устройствах, менеджмент проекта, коммуникации | Широкая аудитория, финансы и персональные данные, частые изменения требований |
| Запуск и эксплуатация | Аккаунты разработчика, хостинг, платные сервисы, мониторинг, поддержка | Большая нагрузка, хранение медиафайлов, SMS, платные API карт и аналитики |
Факторы, которые сильнее всего влияют на бюджет
1. Количество и сложность сценариев
Считать экраны удобно, но обманчиво. Экран «Каталог» может быть простым списком, а может включать фильтры, поиск с подсказками, сортировку, бесконечную прокрутку, избранное и кеширование для работы без сети. Правильнее оценивать сценарии: «найти товар и добавить в корзину», «оформить заказ и оплатить», «отследить статус».
2. Платформы и способ разработки
Две отдельные нативные версии для iOS и Android означают две кодовые базы, две команды или хотя бы два набора навыков. Кроссплатформенная разработка (Flutter, React Native, Kotlin Multiplatform) позволяет переиспользовать значительную часть кода, но не всю: интеграции с системными функциями, публикация и тестирование всё равно делаются для каждой платформы. Подробно — в статье «Нативная или кроссплатформенная разработка».
3. Бэкенд и интеграции
Приложение, которое показывает статичный контент, может обойтись почти без сервера. Как только появляются аккаунты, заказы, синхронизация между устройствами или интеграция с учётной системой компании, серверная часть становится сопоставимой по объёму с мобильной. Интеграции — главный источник неопределённости: документация внешней системы может быть неполной, а тестовая среда — отсутствовать.
4. Требования к безопасности и данным
Приложения, работающие с платежами, медицинскими или финансовыми данными, требуют дополнительного проектирования, тестирования и документов. Если вы обрабатываете персональные данные пользователей, придётся выполнить требования 152-ФЗ: локализация баз данных в России, согласия, политика обработки. Это не только юридическая, но и техническая работа — подробнее в статье «Персональные данные в мобильном приложении».
5. Дизайн
Интерфейс на стандартных системных компонентах обходится заметно дешевле, чем полностью фирменный дизайн с иллюстрациями и анимациями. Для внутренних приложений компании стандартные компоненты — разумный выбор; для потребительского продукта в конкурентной нише инвестиции в дизайн обычно окупаются.
6. Состав и форма работы команды
Фрилансер, небольшая студия, крупное агентство и собственная команда различаются не только ставкой, но и тем, что включено в цену: менеджмент, тестирование, аналитика, гарантийный период, документация. Сравнивая предложения, выясняйте, кто конкретно будет работать над проектом и какие роли учтены в оценке.
Как отдельные функции меняют бюджет
Одна и та же категория приложения стоит по-разному в зависимости от набора функций. Ниже не цены, а относительная оценка того, насколько функция обычно увеличивает объём работ.
| Функция | Что стоит за ней | Влияние на объём | Комментарий |
|---|---|---|---|
| Вход по SMS | Интеграция с SMS-провайдером, защита от накрутки заявок | Низкое–среднее | Есть готовые SDK, нужен резервный канал |
| Онлайн-оплата | Интеграция с эквайрингом, обработка статусов, чеки | Среднее | Для офлайн-услуг эквайринг работает без участия магазина приложений |
| Чат (поддержка или между пользователями) | Хранение сообщений, доставка в реальном времени, модерация | Среднее–высокое | Дешевле подключить готовый SDK, чем писать с нуля |
| Карты и геолокация | Платный API карт и геокодирования | Среднее | Тарификация за число запросов, растёт с аудиторией |
| Офлайн-режим | Локальное хранилище, синхронизация, обработка конфликтов данных | Высокое | Недооценённая задача: конфликты синхронизации отнимают много времени |
| Видео | Загрузка, сжатие, хранение, проигрывание или стриминг | Высокое | Хранение и трафик — постоянная статья расходов |
| Интеграция с 1С или CRM | Обмен данными по API, сопоставление справочников | Среднее–высокое | Зависит от качества документации учётной системы заказчика |
| Программа лояльности | Начисление и списание баллов, история операций, админка | Среднее | Фиксированный кешбэк дешевле гибкой системы уровней |
| Мультиязычность | Перевод интерфейса, форматы дат и валют, тестирование на языке | Низкое–среднее | Растёт с числом языков и их отличием от русского |
| Планшетная версия | Адаптивная вёрстка под больший экран | Среднее | Для кроссплатформы дешевле, чем поддержка двух нативных версий |
Как оценить проект в часах
Надёжная оценка строится снизу вверх: каждый сценарий раскладывается на задачи, задачи — на часы по ролям. Ниже — пример структуры оценки для небольшого приложения записи к специалистам. Числа условные и нужны, чтобы показать, как оценка выглядит, а не чтобы использовать их как норму.
| Модуль | Дизайн | Мобильная разработка | Бэкенд | Тестирование |
|---|---|---|---|---|
| Регистрация и вход по телефону | 8 | 24 | 20 | 10 |
| Список специалистов и услуг | 12 | 32 | 16 | 10 |
| Выбор времени и запись | 16 | 48 | 40 | 20 |
| Мои записи, перенос и отмена | 10 | 28 | 16 | 12 |
| Push-уведомления и напоминания | 4 | 16 | 20 | 8 |
| Профиль и удаление аккаунта | 6 | 16 | 8 | 6 |
| Панель администратора | 16 | — | 60 | 16 |
| Публикация, аналитика, мониторинг | 6 | 16 | 8 | 8 |
| Итого по ролям | 78 | 180 | 188 | 90 |
К сумме часов специалистов обычно добавляют:
- управление проектом — часто это 10–20% от объёма работ;
- резерв на неопределённость — 15–30%, больше для интеграций с внешними системами и новых для команды технологий;
- аналитику и уточнение требований, если они не были сделаны до оценки.
Умножив часы каждой роли на ставку и добавив эти коэффициенты, вы получите собственный ориентир. Если чья-то оценка отличается от него в разы, попросите исполнителя показать декомпозицию: расхождения обычно находятся в конкретных модулях и объясняются разным пониманием требований.
Как читать коммерческое предложение
Прежде чем сравнивать сметы, соберите список требований к приложению — что оно делает, кто им пользуется, какие нужны интеграции (на главной есть памятка, что в него включить). Более формальный вариант того же списка — техническое задание, о нём в статье «Техническое задание на мобильное приложение». Получив смету от подрядчика, задайте по ней несколько прямых вопросов.
- Роли и часы. Сколько часов на дизайн, разработку, бэкенд, тестирование и менеджмент отдельно?
- Состав работ. Входят ли бэкенд и админка, или расчёт только по экранам приложения?
- Правки дизайна. Сколько итераций включено и что будет, если понадобится больше?
- Тестирование. На каких устройствах и ОС тестируют, кто отвечает за баги после релиза?
- Права. Кому принадлежат исходный код и аккаунты в App Store, Google Play, RuStore?
- Гарантия. Есть ли гарантийный период на исправление ошибок и сколько он длится?
- Изменение объёма. Что считается change request и как он оплачивается?
- Публикация. Входит ли размещение в магазинах в стоимость или это отдельная услуга?
- Ставка после релиза. По какой ставке оплачиваются доработки после запуска?
Красные флаги в смете: одна сумма без декомпозиции по ролям; «всё включено» без расшифровки; тестирование не упомянуто как отдельная работа; аккаунты разработчика подрядчик предлагает оформить на себя, а не на вашу компанию. Как проверить исполнителя до подписания и что прописать в договоре — в статье «Как выбрать подрядчика для разработки приложения».
Фиксированная цена или оплата по времени
| Модель | Как работает | Подходит, когда | Риски |
|---|---|---|---|
| Фиксированная цена (fixed price) | Объём, срок и цена фиксируются в договоре | Требования подробно описаны и вряд ли изменятся | Исполнитель закладывает резерв в цену; любые изменения — через допсоглашения |
| Время и материалы (T&M) | Оплачиваются фактически отработанные часы | Продукт будет уточняться по ходу, нужна гибкость | Бюджет сложнее контролировать без прозрачной отчётности |
| Выделенная команда | Оплачивается команда на месяц независимо от задач | Долгосрочное развитие продукта | Нужен сильный продакт-менеджер со стороны заказчика |
| Гибрид | Фикс за аналитику и дизайн, затем T&M или фикс по этапам | Большинство новых продуктов | Требует аккуратного описания этапов и критериев приёмки |
Практичный вариант для нового продукта — сначала оплатить небольшой этап аналитики и прототипа по фиксированной цене. Его результат (требования, прототип, декомпозиция) позволит получить точные оценки разработки у нескольких исполнителей и не зависеть от одного, а список вопросов из раздела выше — сверить эти оценки между собой.
Обязательные платежи и комиссии магазинов
Кроме работы команды, у приложения есть расходы на площадки: сбор Apple за аккаунт разработчика повторяется ежегодно, у Google Play он разовый, а комиссия считается с каждой продажи цифрового товара или подписки внутри приложения. Какие модели заработка возможны и когда комиссия вообще применяется — в статье «Монетизация мобильного приложения».
| Площадка | Регистрационный сбор | Комиссия с продаж и подписок |
|---|---|---|
| App Store (Apple Developer Program) | 99 USD в год | 30% стандартно; 15% по программе для малого бизнеса (доход ниже 1 млн USD в год) и на подписки со второго года |
| Google Play | 25 USD разово | 15% на первый 1 млн USD дохода в год и на подписки с первого дня; выше порога — 30%. Условия меняются — сверяйтесь со справкой в Play Console |
| RuStore | Бесплатно | Порядка 15% за монетизацию (по данным RuStore); точную ставку смотрите в актуальной оферте, правила менялись в 2026 году |
Комиссии касаются только цифровых товаров и подписок через встроенную покупку самого магазина. Доставка, запись на услугу и другие офлайн-услуги обычно оплачиваются через обычный банковский эквайринг — без комиссии магазина, по тарифам эквайера.
Уточните у бухгалтерии, как оплатить зарубежные сборы Apple и Google из России: это может потребовать дополнительных шагов, и их стоит заранее учесть в сроках. Для RuStore с 1 февраля 2026 года платная монетизация доступна только ИП и юрлицам — проверьте свой статус в консоли.
Расходы, которые часто забывают
- Аккаунты разработчика и комиссии магазинов. Ежегодные и разовые сборы, а также комиссии с продаж — разобраны в разделе выше.
- Хостинг и базы данных. Стоимость растёт вместе с числом пользователей, объёмом файлов и требованиями к резервированию.
- Платные сервисы. SMS для входа по номеру телефона, карты и геокодирование, распознавание документов, видеозвонки, email-рассылки — у многих тарификация за каждое обращение.
- Юридические работы: политика конфиденциальности, пользовательское соглашение, согласия на обработку данных, уведомление Роскомнадзора.
- Продвижение: приложение без трафика почти никто не найдёт в магазине. С чего начать — в статье «Продвижение мобильного приложения и ASO».
- Поддержка. Ежегодные обновления под новые версии ОС, исправление ошибок, обновление библиотек. Как планировать этот бюджет — в разделе «Бюджет после релиза» ниже.
Как снизить стоимость без ущерба для продукта
- Сократить первую версию до одного главного сценария. Это самый сильный рычаг. Всё, что не нужно для проверки ценности, переносится в следующие релизы — подход подробно описан в статье о MVP.
- Использовать стандартные компоненты интерфейса там, где фирменный дизайн не даёт конкурентного преимущества.
- Выбрать кроссплатформенную технологию, если приложению не нужны сложные системные функции и максимальная производительность.
- Не писать то, что можно подключить. Авторизация, платежи, чат поддержки, аналитика и мониторинг ошибок есть в виде готовых сервисов и SDK.
- Готовить решения заранее. Каждый день ожидания ответа заказчика при оплате по времени — это деньги. Назначьте одного человека, который принимает решения по продукту.
- Начать с веб-версии или PWA, если нужно лишь проверить спрос, а мобильные возможности вторичны.
На чём экономить не стоит: на тестировании, на безопасности хранения данных, на доступе к исходному коду и на документации. Эти «экономии» почти всегда возвращаются дорогими переделками или зависимостью от одного исполнителя.
Бюджет после релиза
Разработка первой версии — это начало расходов, а не их конец. Кроме инфраструктуры и сервисов, закладывайте время команды на обязательные обновления: Google Play ежегодно поднимает требования к целевому уровню API (с 31 августа 2026 года новые приложения и обновления должны быть нацелены на Android 16, API level 36), а Apple — к версии SDK и Xcode, с которой собираются приложения (с 28 апреля 2026 года — Xcode 26 и SDK iOS 26). Плюс исправление ошибок, найденных пользователями, и развитие функций по результатам аналитики.
Если пропустить эти сроки, приложение не перестанет работать сразу, но потеряет возможность обновляться: магазин откажется принимать новую сборку до соответствия требованиям. Установленная версия ещё поработает, но исправления и видимость новым пользователям окажутся недоступны.
Бюджет поддержки удобно делить на обязательную часть (обновления под новые ОС и SDK, аккаунты, хостинг, мониторинг, критичные баги) и развитие (новые функции по результатам аналитики). Обязательную часть можно зафиксировать в договоре как сумму на год, а бюджет развития — пересматривать поквартально по факту того, какие доработки окупаются. Что входит в поддержку и как её организовать — в статье «Поддержка мобильного приложения после релиза».
Частые вопросы
Почему одно и то же приложение оценивают так по-разному?
Чаще всего исполнители по-разному поняли объём: один заложил простой список, другой — поиск с фильтрами и офлайн-режимом; один учёл админку и тестирование, другой нет. Попросите у всех оценку по одному и тому же списку сценариев и декомпозицию по модулям.
Можно ли узнать цену по примеру похожего приложения?
Только очень грубо. Видимая часть популярного приложения — экраны — обычно меньшая часть работы: за ними стоят серверная логика, интеграции, администрирование и годы доработок. Сравнивайте по функциям первой версии, а не по внешнему виду готового продукта.
Что выгоднее: фрилансер, студия или своя команда?
Для небольшого прототипа может подойти опытный фрилансер. Для продукта с серверной частью, дизайном и тестированием обычно нужна команда с несколькими ролями. Собственная команда оправдана, когда приложение — ключевой продукт компании и развивается постоянно.
Сколько закладывать на резерв?
Обычно 15–30% к оценке. Больше — если есть интеграции с внешними системами без хорошей документации, новые для команды технологии или требования ещё не устоялись.
Дешевле ли кроссплатформенная разработка?
Как правило, да, если приложению не нужны глубокие системные функции: большая часть интерфейса и логики пишется один раз. Но экономия не двукратная — тестирование, публикация и платформенные интеграции остаются отдельными для iOS и Android.
Сколько стоит поддержка приложения?
Зависит от сложности и темпа развития. Для оценки перечислите обязательные работы на год (обновления ОС и библиотек, исправление ошибок, мониторинг, хостинг) и отдельно — планируемые новые функции. Обязательную часть стоит зафиксировать в договоре поддержки.
Можно ли сделать приложение бесплатно на конструкторе?
Конструкторы позволяют бесплатно или за небольшую плату собрать простое приложение — разумный вариант, чтобы проверить идею или сделать небольшой каталог. Но сложные сценарии, интеграция с учётными системами компании, нестандартный дизайн и доступ к исходному коду обычно недоступны или открываются только на дорогих тарифах, а при росте проекта часто нужен переезд на собственную разработку. Сравнивайте лимиты конкретного тарифа с вашим списком сценариев, а не с общим описанием сервиса.
Итог
Стоимость приложения определяется не категорией («приложение для доставки»), а конкретным списком сценариев, платформ, интеграций и требований к качеству. Чтобы получить реалистичную цифру, опишите первую версию, попросите декомпозицию в часах по ролям, сверьте предложение по списку вопросов из раздела «Как читать коммерческое предложение», добавьте резерв и расходы на эксплуатацию — и сразу запланируйте бюджет на год после релиза. Порядок работ, в котором эти решения принимаются, описан в статье «Этапы разработки мобильного приложения».