Заказчик описывает приложение в трёх предложениях, а получает сметы, отличающиеся в пять раз. Это не значит, что кто-то обманывает: под одним описанием прячутся разные объёмы работ. Разберём, из чего складывается цена и на что смотреть при сравнении.
Кто работает над приложением
В нормальном проекте участвуют проектировщик, дизайнер, разработчики под платформы, серверный разработчик, тестировщик и менеджер. Стоимость это их время, а не абстрактная сложность.
Когда смета подозрительно низкая, обычно несколько ролей выполняет один человек, а часть работ не делается вовсе. Первыми выпадают проектирование и тестирование, то есть именно то, что определяет, будет ли приложением удобно пользоваться.
Главный вопрос: сколько платформ
Приложение под iOS и Android можно делать нативно, то есть отдельно под каждую систему, или кросс-платформенно, одним кодом. Нативная разработка дороже примерно вдвое, но даёт максимум скорости и доступ ко всем возможностям телефона.
Для большинства задач бизнеса кросс-платформенный подход закрывает потребности: витрина, заказы, личный кабинет, уведомления. Нативная нужна там, где важны тяжёлая графика, сложная работа с камерой и датчиками, фоновое отслеживание.
Отдельный вариант, о котором забывают: если задача это продажи и переписка, иногда вместо приложения достаточно Telegram Mini App, и это дешевле в несколько раз.
Что удорожает проект больше всего
- Несколько ролей пользователей: клиент, исполнитель, диспетчер. Каждая роль это свой набор экранов и прав.
- Интеграции: учётная система, оплата, доставка, карты, телефония.
- Офлайн-режим и синхронизация данных.
- Чаты, звонки, сложные уведомления по событиям.
- Административная часть: почти всегда недооценивают, а по объёму она сопоставима с самим приложением.
Про Алматы отдельно
Город даёт основную часть спроса на приложения в стране, и здесь же самая высокая конкуренция за разработчиков. Это влияет на цену: сильные команды загружены, а дешёвые предложения чаще приходят от одиночек без тестирования и поддержки.
Вторая особенность: ожидания пользователей. Люди привыкли к быстрым интерфейсам банковских и сервисных приложений, поэтому медленный экран или неудобная форма воспринимаются как поломка, а не как мелочь.
Расходы после запуска
Приложение это не разовая покупка. Ежегодно нужны продление аккаунтов разработчика, обновления под новые версии систем, серверы, поддержка и исправления. Системы меняются каждый год, и без обновлений приложение со временем перестаёт собираться.
Заложите на это бюджет заранее. Ситуация, когда приложение сделано, а денег на поддержку нет, встречается чаще, чем кажется, и заканчивается тем, что через полтора года его приходится переписывать.
Публикация в сторах
Это отдельный этап со своими сроками и требованиями: аккаунты, политика конфиденциальности, описания, скриншоты, проверка. Первая публикация почти всегда дольше, чем ожидают, потому что часть требований выясняется по ходу.
Подробности по этому этапу разобраны на страницах публикации в App Store и регистрации аккаунта разработчика.
Как сравнивать предложения
Просите разбивку по этапам и списку экранов. Уточняйте, входит ли административная часть, тестирование, публикация и поддержка. Спрашивайте, кому принадлежит код и аккаунты после сдачи: они должны быть оформлены на вашу компанию.
И задайте вопрос, который отсекает половину слабых предложений: что произойдёт, если через месяц после запуска обнаружится ошибка. Ответ покажет, заложена ли гарантия и кто будет её выполнять.
С чего начать, если бюджет ограничен
С первой версии, где доведён до конца один ключевой сценарий: зарегистрировался, выбрал, оплатил, получил. Она проверяет гипотезу на живых пользователях и стоит примерно треть от полного продукта.
Состав работ и ориентиры по срокам есть на странице разработки мобильных приложений. Обсудить задачу можно через контакты.
Что входит в административную часть
Её почти всегда недооценивают при оценке, а по объёму она сопоставима с самим приложением. В панели живут пользователи и их статусы, заказы или заявки, справочники, цены, уведомления, отчёты и права доступа для разных сотрудников.
Если панель не заложена в смету, после запуска выясняется, что менять данные некому и нечем, и работа делается через разработчика за отдельные деньги. Поэтому вопрос «что я смогу менять сам» задавайте до подписания.
Тестирование: на чём экономят зря
Проверка на живых устройствах отличается от проверки на эмуляторе. Старые телефоны с маленьким экраном, слабый интернет, обрыв связи посреди оплаты, нехватка места в памяти: именно эти состояния встречает реальный пользователь.
Экономия на тестировании выглядит выгодной ровно до первых отзывов в сторах. Исправлять после публикации дороже, а плохая оценка в карточке приложения снижает установки надолго.
Сроки по этапам
Простое приложение с одним сценарием собирается за шесть-десять недель, включая публикацию. Проект с несколькими ролями, интеграциями и админкой это от трёх месяцев. Сроки считаются от момента, когда получены доступы и согласован прототип, а не от даты договора.
Отдельная статья это ожидание доступов: эквайринг, рассылки, аккаунты разработчика оформляются на вашей стороне и занимают от нескольких дней до нескольких недель. Запускать это оформление нужно в первый же день проекта.
Сравнение вариантов по деньгам
- Первая версия с одним сценарием: примерно треть от полного продукта, проверяет спрос на живых пользователях.
- Кросс-платформенная разработка: один код на две системы, экономия заметная, подходит большинству задач бизнеса.
- Нативная разработка: дороже вдвое, нужна при тяжёлой графике, сложной работе с камерой и датчиками.
- Mini App в мессенджере: дешевле всех, если задача это витрина, заказы и переписка.
Выбор делается не по красоте технологии, а по тому, что должно работать в приложении через год.