Сколько стоит мобильное приложение и из чего складывается цена
Честный разбор сметы: почему «приложение как у…» невозможно оценить одной цифрой, из каких статей складывается стоимость и как повлиять на бюджет, не жертвуя качеством.
«Сколько стоит сделать приложение?» — вопрос, на который честный ответ звучит как «зависит», и это раздражает. Поэтому давайте разберём, от чего именно зависит, чтобы вы могли влиять на цифру осознанно, а не выбирать между «дорого» и «подозрительно дёшево».
Почему нет одной цены
Стоимость приложения — это не прайс на готовый товар, а оценка работы под конкретную задачу. Два приложения с одинаковой иконкой в сторе внутри могут отличаться в разы: у одного три экрана и одна интеграция, у другого — роли, платежи, офлайн-режим и админка. Поэтому вопрос «сколько стоит» на деле означает «сколько работы», а работа складывается из вполне понятных статей.
Дизайн · разработка iOS · разработка Android (или общая кодовая база) · backend и API · интеграции · тестирование · выкладка в сторы · поддержка после релиза. Убрать можно этапы, но не статьи — «сэкономленное» тестирование всегда возвращается счётом за багфиксы.
Что двигает цену сильнее всего
- Количество платформ. iOS + Android нативно — почти две сметы. Кроссплатформа складывает их в одну кодовую базу и заметно снижает стоимость.
- Число и сложность экранов. Не «страниц», а уникальных состояний: пустые экраны, ошибки, загрузка, роли пользователей — всё это отдельная работа.
- Backend. Есть готовый API — дешевле. Нужно проектировать сервер, авторизацию и админку с нуля — это половина проекта.
- Интеграции. Платежи, карты, пуши, аналитика, чужие API — каждая тянет настройку, обработку ошибок и тесты.
- Уровень отделки. Кастомная анимация и выверенный дизайн стоят дороже стандартных компонентов — иногда это оправданно, иногда нет.
Дешёвое приложение и дорогое чаще всего отличаются не тем, что видно в сторе, а тем, что не видно: тестами, обработкой ошибок и архитектурой, с которой продукт можно развивать.
Скрытые статьи, о которых забывают
Смета на «сделать» — это не вся стоимость владения. К ней добавляются: аккаунты разработчика в App Store и Google Play, серверная инфраструктура, платные сервисы (пуши, аналитика, карты), поддержка под новые версии ОС дважды в год и развитие продукта. Приложение — не разовая покупка, а живой сервис, и планировать стоит стоимость первого года, а не только релиза.
Как повлиять на бюджет без потери качества
- Начните с MVP. Один ключевой сценарий доведённый до ума дешевле и полезнее десяти сырых фич. Остальное — по данным после релиза.
- Одна платформа на старте. Выпустите там, где ваша аудитория, проверьте гипотезу, потом расширяйтесь.
- Готовые решения под неключевое. Авторизацию, аналитику, пуши не нужно писать с нуля — экономия идёт в ваш уникальный функционал.
- Не экономьте на дискавери. Несколько дней проектирования снимают недели переделок — это самая выгодная статья сметы.
Почему мы называем цену только после дискавери
Оценка «на глаз» по описанию в двух предложениях — это либо перестраховка (цифра с большим запасом), либо ловушка (низкая цифра, которая вырастет по ходу). Поэтому мы сначала собираем карту экранов и список интеграций, а уже потом даём смету с понятной структурой — где видно, за что именно вы платите и что можно отложить.
Коротко
- Цена = объём работы, а не тип продукта. Двигают её платформы, экраны, backend и интеграции.
- Считайте стоимость первого года, а не только релиза.
- MVP и одна платформа — законные способы уменьшить бюджет без потери качества.
- Точная смета живёт после дискавери, а не в первом письме.
Обсудить ваш проект →
