Большинство компаний, которые говорят «хочу заказать мобильное приложение», первым делом спрашивают о цене. Но цену определяет объём: какую задачу решает приложение, кто им пользуется и какая система стоит за ним. В этом руководстве — порядок действий, точки принятия решений и реальные диапазоны стоимости.
Сначала вопрос: вам действительно нужно приложение?
Будем честны: в части обращений приложение — неверное решение. В трёх ситуациях мобильное приложение — это выброшенные деньги:
- Если пользователь открывает его 2–3 раза в год. Люди не устанавливают на телефон то, чем будут пользоваться трижды в год. Сайт с мобильной адаптацией справится с той же задачей.
- Если приложение — точная копия сайта. Если нет дополнительной ценности, нет и причины скачивать его из магазина.
- Если у вас пока нет трафика и клиентской базы. Приложение хорошо удерживает существующих клиентов, но плохо находит новых.
Зато в этих случаях приложение явно окупается: частое повторное использование (заказы, бронирование, отслеживание), процессы, где нужны уведомления, работа без интернета, использование функций устройства вроде камеры, геолокации или NFC, а также работа выездных сотрудников.
Шаг 1: Опишите сценарий использования
Прежде чем рисовать экраны, напишите одно предложение: «[Кто] откроет приложение [в какой ситуации], [чтобы сделать что]».
Пример: «Торговый представитель дилера откроет его во время визита к клиенту, чтобы посмотреть остатки и оформить заказ». Когда это предложение сформулировано, нужные экраны появляются сами собой — и, что ещё важнее, становится видно, какие из них не нужны.
Другие вопросы, на которые нужно ответить:
- Приложение будет служить клиентам, сотрудникам или дилерам?
- Нужны ли регистрация, оплата, уведомления или карты?
- Будет ли панель для управления контентом?
- Выходят ли iOS и Android одновременно?
- Зачем пользователь откроет приложение во второй раз?
Последний вопрос самый важный. Если на него нет ответа, проект окажется успешным технически и провальным коммерчески.
Шаг 2: Натив или кроссплатформа?
| Натив (Swift / Kotlin) | Кроссплатформа (React Native / Flutter) | |
|---|---|---|
| Стоимость | Две отдельные кодовые базы, дороже примерно на 60–80% | Одна кодовая база |
| Производительность | Максимальная | Достаточная для большинства бизнес-приложений |
| Функции устройства | Полный доступ | Большинство готово, для некоторых нужен мост |
| Обновления | Две команды, два процесса | Одна разработка |
| Когда нужен | Тяжёлая графика, игры, интенсивная работа с камерой/сенсорами | Заказы, бронирование, каталог, выездная работа, контент |
На практике для подавляющего большинства бизнес-приложений правильный ответ — кроссплатформа. React Native и Flutter в стандартных бизнес-сценариях дают опыт, неотличимый от нативного, и сокращают бюджет почти вдвое. Натив стоит оставить для проектов, которые используют железо устройства на пределе.
Шаг 3: Определите объём MVP
MVP — это минимальная, но реально пригодная к использованию первая версия приложения. Её цель — не урезать функции, а как можно скорее дать ключевую ценность в руки реальным пользователям.
В MVP входит: экраны, завершающие основной сценарий, вход и базовая админ-панель.
В MVP не входит: шеринг в соцсети, система значков/баллов, мультиязычность, расширенная отчётность, выбор темы оформления.
В проектах, где такого разделения нет, происходят две вещи: дата запуска сдвигается с 3 до 9 месяцев, а половиной выпущенных в итоге функций никто не пользуется. Подробно логику MVP мы разобрали в руководстве по MVP мобильного приложения.
Шаг 4: Панель и API — невидимая половина
За большинством мобильных приложений стоят веб-панель и API. Обычно на них приходится 40–50% бюджета. С самого начала нужно спланировать:
- Управление пользователями и правами доступа
- Управление контентом/товарами/услугами
- Поток заказов или заявок
- Экран отправки уведомлений
- Базовую отчётность
В приложениях, сделанных без продуманной панели, каждое изменение контента идёт через разработчика, приходится ждать обновления в магазине, и операционная работа встаёт. Решение «сделаем приложение, а панель потом» в итоге обходится дороже всего.
Если у вас уже есть система (ERP, бухгалтерия, интернет-магазин), приложение должно с ней взаимодействовать; это отдельная статья — API-интеграция.
Шаг 5: Публикация в магазинах
Публикация в App Store и Google Play — это не «загрузил код и готово». Нужно подготовить:
- Название приложения и описание для магазина (работа по ASO)
- Скриншоты для каждого размера устройства
- Ссылку на политику конфиденциальности и декларацию об использовании данных
- Пояснения к разрешениям (камера, геолокация, уведомления — каждое с обоснованием)
- Тестовый аккаунт и заметки для проверки Apple
- Аккаунты разработчика: Apple — 99 USD в год, Google — 25 USD единоразово
При первой отправке Apple часто отклоняет приложения; запрос разрешений без обоснования и неполная декларация конфиденциальности — самые частые причины отказа. Если оставить эту подготовку на конец, публикация задерживается на 2–3 недели.
Стоимость и сроки
| Объём | Срок | Бюджет |
|---|---|---|
| MVP (5–8 экранов, панель, один сценарий) | 8–12 недель | 100 000–200 000 TL |
| Средний (оплата, уведомления, интеграция) | 3–5 месяцев | 200 000–450 000 TL |
| Масштабный (много ролей, связь с ERP, офлайн) | 6+ месяцев | от 450 000 TL |
Наш пакет разработки мобильных приложений начинается от 100 000 TL + НДС (KDV — турецкий налог на добавленную стоимость). Что и как меняет цену, мы по пунктам разобрали в статье о ценах на мобильные приложения.
Что нужно добавить в бюджет: ежегодные аккаунты разработчика, стоимость серверов и, самое главное, поддержку. iOS и Android каждый год выпускают по крупной версии; приложения без обновлений через 18–24 месяца рискуют пропасть из магазина. Реалистично закладывать на годовую поддержку 15–20% стоимости проекта.
Что должно быть в грамотном коммерческом предложении?
Получая предложение, попросите письменно указать:
- Список экранов и схему пользовательских сценариев
- Объём работ для iOS и Android по отдельности
- Объём админ-панели и API
- Специальные модули: уведомления, оплата, карты, подписки
- Процесс тестирования и критерии приёмки
- Помощь с публикацией в магазинах (открытие аккаунтов, отправка, работа с отказами)
- Срок и объём поддержки после запуска
- Кому будут принадлежать исходный код и аккаунты в магазинах
Последний пункт часто пропускают, и потом он становится проблемой: если аккаунт в магазине открыт на имя разработчика, полного контроля над приложением у вас нет. Аккаунты всегда должны открываться на вашу компанию.
Часто задаваемые вопросы
За сколько месяцев делается приложение?
Для MVP реалистично 8–12 недель: 2 недели на дизайн, 6–8 недель на разработку, 1–2 недели на тестирование и публикацию в магазинах.
С какой платформы начать?
В Турции пользователей больше на Android, а тратят больше на стороне Apple. Если выбрать кроссплатформу, этот вопрос и так отпадает.
Сможет ли другая команда потом взять приложение на поддержку?
Да, если исходный код передан вам и задокументирован. Этот пункт в договоре избавляет от зависимости от подрядчика.
Нужно ли приложение, если у меня уже есть сайт?
Вернитесь к трём пунктам в начале статьи. Если пользуются редко, сайт с мобильной адаптацией — более разумная инвестиция.
С чего начнём
Опишите сценарий использования одним абзацем и пришлите нам — мы бесплатно определим, что войдёт в MVP, и оценим сроки.
Телефон / WhatsApp: +90 536 628 0007
E-mail: info@enextware.com
