Вопрос «сколько стоит приложение» звучит примерно как «сколько стоит здание». Ответ зависит от того, что внутри, на сколько людей рассчитано и что должно происходить, когда всё пойдёт не по плану. Ниже — структура, по которой считается смета, и факторы, которые двигают её сильнее всего.
Реальные диапазоны цен
Начнём с цифр, чтобы дальше было от чего отталкиваться. Это ориентиры российского рынка для команд среднего уровня — не фрилансеров и не крупных интеграторов.
| Тип проекта | Бюджет | Срок |
|---|---|---|
| MVP с одним сценарием | 200 000 – 500 000 ₽ | 8–12 недель |
| Приложение с лояльностью и оплатами | 700 000 – 1 500 000 ₽ | 4–6 месяцев |
| Платформа для сети с интеграциями | 1 500 000 – 4 000 000 ₽ | 6–12 месяцев |
| Высоконагруженный сервис | от 4 000 000 ₽ | от 9 месяцев |
Если вам называют 150 тысяч за приложение с оплатами и интеграцией с 1С — это не выгодное предложение, а неверно понятая задача. Такие проекты заканчиваются одинаково: сначала «доплатите за то, чего не было в ТЗ», потом переписывание с нуля другой командой.
Из чего состоит смета
Разработка — это не только программирование. В типовом проекте написание кода занимает примерно половину бюджета, остальное распределяется так:
- Аналитика и проектирование — 10–15%. Описание сценариев, логика экранов, структура данных, спецификация интеграций. Этап, который чаще всего пытаются урезать и от которого потом больше всего страдают.
- Дизайн — 10–20%. Прототипы, визуал, состояния экранов, адаптация под разные размеры, дизайн-система для дальнейшего развития.
- Разработка клиента — 30–40%. Собственно приложение под iOS и Android.
- Серверная часть и админка — 20–30%. API, база данных, панель управления, права доступа. Невидимая для заказчика часть, которая часто больше клиентской.
- Тестирование — 10–15%. Ручное и автоматизированное, на реальных устройствах, включая старые модели.
- Запуск и публикация — 3–5%. Настройка инфраструктуры, аккаунты разработчика, прохождение модерации сторов.
Если в предложении подрядчика есть только строка «разработка приложения» с одной цифрой — попросите разбивку. Отсутствие структуры обычно означает, что оценка сделана на глаз.
Что двигает цену сильнее всего
1. Интеграции, а не количество экранов
Это главное недопонимание между заказчиком и подрядчиком. Заказчик считает экраны, подрядчик считает связи с внешним миром. Каталог товаров из десяти экранов, где данные загружаются файлом раз в сутки, и такой же каталог, где остатки и цены приходят из 1С в реальном времени с учётом резервов, — это разница в разы.
Каждая интеграция несёт в себе не только код обмена, но и обработку ошибок: что делать, если система недоступна, если данные пришли в неожиданном формате, если операция прошла наполовину. Именно эта «невидимая» логика съедает время.
2. Состояние вашей IT-инфраструктуры
Если у ваших систем есть документированное API — интеграция превращается в понятную задачу. Если API нет, версия 1С кастомизирована пятью подрядчиками за десять лет, а логика обмена живёт в голове одного человека — сначала придётся построить интеграционный слой. Это отдельный проект внутри проекта.
3. Требования к нагрузке
Приложение на тысячу пользователей и приложение на сто тысяч — архитектурно разные системы. Во втором случае нужны кеширование, очереди, горизонтальное масштабирование, отказоустойчивость и нагрузочное тестирование. Закладывать это «на будущее» при тысяче пользователей — переплата, не закладывать при ста тысячах — гарантированное падение в час пик.
4. Платформы и стек
Кроссплатформенная разработка на Flutter или React Native экономит до 40% по сравнению с двумя нативными командами. Нативная разработка оправдана при тяжёлой графике, работе с Bluetooth, AR или сложных фоновых сценариях. Для большинства бизнес-приложений — каталог, запись, заказ, лояльность, кабинет — кроссплатформы достаточно.
5. Уровень команды
Разница между джуниором и сеньором не в скорости набора кода, а в количестве принятых решений, которые не придётся переделывать через полгода. Дешёвая команда экономит вам деньги на этапе разработки и возвращает этот счёт с процентами на этапе развития.
Правило, которое стоит запомнить: экономия на аналитике и архитектуре — это не снижение стоимости проекта, а её перенос на более поздний этап, где всё дороже.
Расходы, о которых забывают
Смета на разработку — не полная стоимость владения. После запуска появляются регулярные статьи, которые нужно закладывать в бюджет с самого начала:
- Аккаунты разработчика. Apple — 99 $ в год, Google Play — единоразово 25 $, RuStore — бесплатно.
- Серверы и инфраструктура. От нескольких тысяч рублей в месяц для небольшого проекта до сотен тысяч для нагруженного.
- Сторонние сервисы. Push-рассылки, SMS, аналитика, мониторинг ошибок, карты, эквайринг — каждый со своим тарифом.
- Поддержка и обновления. Обычно 10–20% от стоимости разработки в год. iOS и Android выпускают мажорные версии ежегодно, и приложение, которое не обновляют, начинает ломаться само по себе.
- Развитие. Самая недооценённая статья. Приложение, в которое не добавляют ничего после релиза, теряет аудиторию за несколько месяцев.
- Привлечение установок. Приложение само себя не найдёт. Нужны QR-коды в точках, работа персонала, стимулы за установку, иногда реклама.
На чём можно экономить, а на чём нельзя
Можно: сократить набор функций на старте до одного ключевого сценария, отказаться от анимаций и сложной графики, использовать кроссплатформу, взять готовые решения для второстепенных задач, запуститься на одной платформе, если ваша аудитория явно смещена.
Нельзя: аналитика и проектирование, архитектура серверной части, тестирование, обработка ошибок интеграций, безопасность данных. Всё, что не видно в интерфейсе, но определяет, будет ли продукт работать через год.
Как сравнивать предложения подрядчиков
Если оценки различаются в разы, дело почти всегда не в жадности, а в разном понимании задачи. Прежде чем сравнивать цифры, задайте всем одинаковые вопросы:
- Что именно входит в смету — есть ли там аналитика, дизайн, серверная часть, тестирование, публикация?
- Как считается серверная часть и админка? Часто их «забывают» в дешёвых предложениях.
- Что происходит при изменении требований в процессе — фиксированная смета или почасовая работа?
- Кому принадлежит код и передаются ли доступы к инфраструктуре?
- Что входит в гарантию и сколько она длится?
- Сколько стоит поддержка после запуска?
- Можно ли посмотреть работающие проекты и поговорить с их заказчиками?
После этих вопросов разброс обычно сокращается: становится видно, что дешёвое предложение просто не включало половину работ.
Главный вопрос — не цена, а окупаемость
Приложение за 300 тысяч, которым никто не пользуется, дороже приложения за 2 миллиона, которое приносит дополнительную выручку каждый месяц. Поэтому считать стоит не бюджет разработки, а срок возврата вложений.
Простая модель: возьмите количество активных клиентов, среднюю частоту покупок и средний чек. Прикиньте, на сколько процентов может вырасти частота, если у клиента появится удобный канал заказа и напоминания. Даже небольшой рост на заметной базе даёт сумму, с которой уже можно сравнивать смету.
Если расчёт не сходится — приложение вам пока не нужно, и честный подрядчик скажет это прямо. Мы разбираем такую экономику на первом созвоне ещё до того, как считать смету: как мы оцениваем проекты по разработке приложений.