Мобильное приложение обходится дороже сайта в несколько раз. Причина проста: за фасадом — минимум две платформы, отдельный сервер с базой данных и команда из шести-восьми специалистов вместо двух-трёх. Разработка мобильного приложения под ключ у Toimi начинается от 1,5 млн ₽ за проект (прод, 29.09.2026); в эту сумму входит iOS, Android и бэкенд. Ниже — разбор по статьям расходов и калькулятор для прикидки своей сметы.
Из чего складывается цена
Три статьи расходов формируют смету любого приложения. Первая — клиентская часть. Это то, что видит пользователь на экране телефона. Для iOS и для Android эта часть не совпадает, если не выбрана кроссплатформенная разработка. Вторая — бэкенд. Это сервер, база данных и API, через которые приложение получает и отправляет информацию. Без бэкенда не работает даже простая авторизация по номеру телефона. Третья — дизайн, тестирование и публикация в сторах. Сюда входят макеты экранов, проверка на разных устройствах и прохождение модерации App Store и Google Play.
На проде Toimi 29.09.2026 цены совпадают на двух страницах: разработка на iOS — от 120 000 ₽, разработка на Android — от 120 000 ₽ (обе — страница мобильной разработки и прайс-лист). Это стартовая цена платформы как отдельного этапа, а не готового продукта: полный проект с обеими платформами и бэкендом — от 1,5 млн ₽. Дизайн приложения на прайс-листе оценён отдельной строкой — от 100 000 ₽.
iOS, Android или кроссплатформа: что дешевле на старте
Кроссплатформенная разработка (Flutter, React Native — один код для обеих платформ) выглядит дешевле на бумаге: на прайс-листе Toimi цена от 700 000 ₽ против совокупных 240 000 ₽ за старт двух нативных платформ. Разница объясняется объёмом. Нативная цена «от 120 000 ₽» — это стоимость одного этапа, а не всего продукта. Кроссплатформенная цифра уже включает готовый MVP на обеих платформах сразу. Кроссплатформенный подход экономит на дублировании логики, но интерфейс всё равно подгоняют под каждую ОС: иначе приложение выглядит чужим и на iOS, и на Android одновременно.
Для Android есть дополнительный шаг после Google Play. Публикация в RuStore нужна большинству приложений для российской аудитории, у которой Google Play не всегда доступен на устройстве . Модерация там своя. Закладывать её в срок нужно с запасом, не в последнюю неделю перед запуском.
Команда и зарплаты: почему час специалиста определяет смету
Минимальная команда мобильного проекта — разработчик под каждую платформу (или один под кроссплатформенный стек), бэкенд-разработчик, дизайнер и тестировщик. На проектах сложнее добавляются архитектор и проджект-менеджер. Здесь и рождается основная часть суммы. Зарплата специалиста умножается на месяцы разработки, а не на строки кода.
По данным исследования Хабр Карьеры за первое полугодие 2026 (опубликовано 28.08.2026), медианная зарплата мобильного разработчика в Москве — 295 000 ₽ в месяц. По языкам цифры такие: iOS-разработчик (Swift) 326 000 ₽, Android-разработчик (Kotlin) 320 000 ₽. Рыночные вилки по всему проекту тоже публичны: по данным Surf на 10.08.2026, простое MVP-приложение на рынке обходится в 1,5–3 млн ₽, среднее по сложности (e-commerce, доставка) — 3–7 млн ₽, а сложное (финтех, своя архитектура) — от 8 млн ₽; часовая ставка senior-разработчика на iOS, Android или Flutter — 4 000–7 000 ₽. Дороже специалист — длиннее список задач, которые он умеет закрывать без переделок.
Экосистема вокруг приложения: то, что не входит в разработку
Само приложение редко работает в одиночку. Приложению для доставки нужна логистика и связь с курьерами. Сервису с личным кабинетом — CRM, куда попадают данные о клиенте. Любому приложению с оплатой — эквайринг и 54-ФЗ. Эти системы закладывают в бюджет сверх разработки самого приложения. Часто именно здесь смета вырастает вдвое против первой цифры от студии.
Ещё одна статья расходов — предпроектные исследования: проверка, нужно ли вообще приложение аудитории, до того как деньги потрачены на разработку. Для мобильного геймдева или сложного B2C-сервиса такие исследования — не роскошь на старте. Это способ не потратить бюджет на то, чем никто не будет пользоваться. Собирают кликабельный прототип, запускают на него рекламу и смотрят на конверсию в клики.
Что можно отложить на вторую очередь
Не всё нужно закладывать в первый релиз. Минимальный набор экранов — каталог, карточка, корзина или заявка, оплата — можно вывести в MVP и проверить спрос на живых пользователях, прежде чем достраивать остальное . На вторую очередь уходят программы лояльности, расширенная аналитика, интеграция с дополнительными системами оплаты и push-уведомления с персонализацией.
| Что | Первый релиз | Вторая очередь |
| Каталог, карточка, заявка | Да | — |
| Базовая оплата | Да | — |
| Push-уведомления о статусе заказа | Да | — |
| Программа лояльности и бонусы | — | Да |
| Расширенная аналитика в кабинете | — | Да |
| Персонализация и рекомендации | — | Да |
| Второй способ оплаты (например, рассрочка) | — | Да |
Калькулятор: приложение доставки по экранам и часам
Ниже — ориентировочная раскладка часов для приложения доставки еды с трекингом заказа, отдельным кабинетом курьера и панелью ресторана. Часы усреднены по типовому проекту такого масштаба и распределяют работу между iOS, Android и бэкендом вместе; это не смета конкретного заказа, а шаблон для прикидки своего бюджета.
| Экран или функция | Часы (все платформы) | Доля бюджета |
| Авторизация и профиль | 60 | 5 % |
| Каталог заведений и меню | 100 | 8 % |
| Карточка блюда и корзина | 80 | 6 % |
| Оформление заказа и оплата | 120 | 10 % |
| Трекинг заказа на карте | 160 | 13 % |
| Push-уведомления о статусе | 40 | 3 % |
| Приложение курьера (отдельная сборка) | 200 | 16 % |
| Панель ресторана и админка | 180 | 14 % |
| Интеграция эквайринга и 54-ФЗ | 100 | 8 % |
| Дизайн интерфейса всех экранов | 130 | 11 % |
| Тестирование и публикация в сторах | 80 | 6 % |
Из таблицы видно: трекинг заказа на карте и отдельное приложение курьера съедают почти треть бюджета — это те части, которые проще отложить, если запускается пилот в одном районе . Панель ресторана можно заменить на ручную выгрузку заказов в чат на первых неделях, а вернуться к полноценной админке после того, как модель подтвердит спрос.
Частые вопросы
Правда ли, что кроссплатформенная разработка всегда дешевле нативной?
Не всегда. Кроссплатформенный стек экономит на общей бизнес-логике, но интерфейс всё равно адаптируют под каждую ОС. Сложная анимация или доступ к специфичным функциям устройства иногда требуют нативного кода поверх общего каркаса. На простых и средних приложениях экономия заметна, на сложных — не гарантирована.
Сколько стоит поддержка приложения после запуска?
Зависит от объёма доработок и от того, что уже входит в саму разработку. Смету поддержки после запуска студия считает отдельным пунктом — спрашивайте её при обсуждении проекта, а не после сдачи.
Можно ли сократить команду и сэкономить на зарплатах?
Частично. Один разработчик на кроссплатформенном стеке заменяет двух нативных, но дизайнера, тестировщика и бэкенд-разработчика сократить нельзя без риска для качества: без тестировщика ошибки находит уже пользователь в сторе.
Почему разработка сайта дешевле разработки приложения при похожем функционале?
Потому что сайт — одна кодовая база под один браузер-движок, а приложение — минимум одна, чаще две отдельные платформы с собственными правилами публикации и обновления. Плюс модерация в App Store и Google Play, которой у сайтов нет.
Стоит ли экономить на предпроектных исследованиях?
Нет, если аудитория и спрос не очевидны до старта. Дешевле потратить время на кликабельный прототип и тестовую рекламу, чем узнать об отсутствии спроса после полной разработки, когда бюджет уже потрачен.