Сколько стоит разработка мобильного приложения

Под словом «приложение» скрываются принципиально разные вещи. Нижняя граница чужих вилок — это клиент без серверной части, собранный по шаблону. Верхняя — нагруженный продукт с десятком интеграций, своей аналитикой и командой на год. Между ними вся вселенная задач.

Назвать одну цифру для них — не упрощение, а дезинформация. Читатель уносит в голове «мне нужно примерно пять миллионов», хотя его проект может стоить и вдвое меньше, и втрое больше.

У этой неопределённости есть инженерное имя — конус неопределённости. На старте, когда есть только идея, честная оценка расходится с итогом в разы в обе стороны. По мере того как проясняются требования, конус сужается, и оценка становится точнее.

Отсюда практический вывод. Подрядчик, который называет точную сумму до всякой аналитики, не демонстрирует экспертизу, а имитирует её: точность оценки физически не может опережать ясность требований. Как этот признак выглядит у конкретных студий, видно в обзоре разработчиков мобильных приложений.

Чужие вилки в статьях устроены просто. Берётся портфель проектов компании, из него выбираются крайние значения, и получается диапазон, внутри которого лежит примерно всё. Полезной информации в нём столько же, сколько в утверждении, что человек весит от сорока до двухсот килограммов.

Что действительно можно узнать до брифа — порядок величины. Приложение с одним сценарием и без интеграций, приложение с личным кабинетом и оплатой, приложение с десятком связей с внутренними системами — это три разных порядка, и разница между ними не в процентах, а в разах. Определить свой порядок вы можете сами, дочитав до главы про множители.

Написание кода — это примерно половина бюджета. Остальное распределяется между работами, которые кажутся необязательными ровно до момента, когда их не сделали. Приведённые доли типичны для заказной разработки; в конкретном проекте они сдвигаются, но порядок сохраняется.

Заказчик рассылает одно и то же описание в пять компаний и получает 2, 3, 4 и 7 млн ₽. Первая мысль — кто-то жадный. На практике дело почти всегда в другом: сметы отвечают на разные вопросы, потому что одно и то же ТЗ прочитано по-разному.

Понимая эти множители, вы прикинете порядок своего проекта и проверите логику любого КП.

Число в смете берётся не с потолка, и понимание метода объясняет, почему честная оценка — это диапазон.

По аналогии. Сравнение с похожими прошлыми проектами. Быстро и грубо, годится на старте, когда деталей мало.

Через декомпозицию. Продукт разбивают на функции, функции — на задачи, оценивают каждую мелкую задачу и складывают. Чем мельче кусок, тем точнее оценка, и сумма получается достовернее, чем прикидка «всего проекта» одним махом.

Через относительную сложность. Команда оценивает не часы, а насколько одна задача сложнее другой. Человек плохо угадывает абсолютные сроки, но хорошо чувствует пропорции; накопленная скорость команды переводит эти оценки в календарь.

Тремя точками. Для задачи дают оптимистичную, реалистичную и пессимистичную оценку и выводят среднюю с весом. Так в смету попадает разброс, который есть у любой работы.

Через отдельную аналитику. Когда требований мало, проводят короткий предпроектный этап и только после него дают точную оценку. Вы платите за небольшую предварительную работу и получаете смету, которой можно верить. Детальный разбор методики — в материале про оценку стоимости разработки.

Проверить чужую оценку можно и без знания методики. Посмотрите, есть ли в смете разброс: одна цифра на задачу означает, что подрядчик либо не оценивал, либо уже спрятал запас внутрь. Посмотрите, соотносятся ли доли этапов с таблицей выше: если на тестирование заложено два процента бюджета, тестирования в проекте не будет. И посмотрите на самую дорогую строку — обычно это либо интеграции, либо сложная функция, и именно её стоит обсудить подробно.

Сравнивать предложения по итоговой цифре бессмысленно. Сравнивают по объёму работ за эту цифру.

В нормальной смете есть разбивка по этапам и ролям, явный список того, что входит и что не входит, и заложенный резерв на непредвиденное. Строка «разработка приложения» с одной суммой — не смета, а число.

Читать её удобно с трёх вопросов. Что именно входит в каждую функцию — тот самый разброс из таблицы выше. Кто отвечает за интеграции и что происходит, если чужая система окажется не готова. Что считается завершением работ и по каким критериям вы будете принимать результат.

Отдельно стоит различать «дёшево» и «недооценено». Дёшево — когда подрядчик сознательно работает по низкой марже или урезал понятный объём. Недооценено — когда он не разглядел сложность и назвал цифру, которую не вытянет.

Второе опаснее. Такой проект либо встанет на середине, либо превратится в поток допсоглашений. Самое дешёвое предложение на старте регулярно оказывается самым дорогим в финале, и доплачиваете вы обычно уже другому подрядчику.

Полезная привычка — просить смету в виде таблицы с трудозатратами по задачам, а не только с итоговыми суммами по этапам. Часы говорят больше денег: по ним видно, сколько работы подрядчик реально видит за каждой функцией, и их легко сравнить между предложениями, даже если ставки у компаний разные.

К нормальной смете прилагается ещё три вещи. Календарный план с датами этапов и указанием, что вы получаете на каждом. Список допущений — на чём подрядчик строил оценку и что произойдёт, если допущение не подтвердится. И порядок изменений: как оформляется правка требований и как она отражается на цене и сроке. Отсутствие этих приложений само по себе не делает КП плохим, но их наличие сильно сокращает количество будущих споров.

Пять признаков, по которым видно проблемное КП ещё до подписания.

Смета одной строкой. «Разработка мобильного приложения — N рублей». Непонятно, что внутри, и сравнить не с чем.

«Всё включено» без списка исключений. Либо в цену зашита большая подушка, либо половину работ в неё не положили. Нормальное КП содержит раздел «не входит», и это признак зрелости.

Нет аналитики и тестирования в составе работ. Их не сэкономили, а переложили на вас в виде будущих переделок.

Сроки и состав «как у всех». Если в КП не видно ваших интеграций и вашей нагрузки, проект не разбирали, а подставили в шаблон.

Оценка без единого уточняющего вопроса. Любое реальное ТЗ порождает вопросы. Их отсутствие означает, что подрядчик либо не читал, либо заложил запас на всё, чего не понял.

Сроки, которые не бьются с составом работ. Если в смете сорок функций, а срок — два месяца, кто-то ошибся. Обычно это означает, что в план не заложили тестирование и стабилизацию, и они всплывут задержкой уже после того, как вы построите под релиз маркетинг.

Что делать с найденным флагом. Не отсеивать подрядчика сразу, а задать прямой вопрос по конкретной строке. Хорошая команда либо объяснит логику, либо признает пробел и пересчитает. Плохая начнёт объяснять, что «так у всех», — и это тоже ответ.

Одно и то же изменение стоит по-разному в зависимости от того, когда его внесли. Это главный аргумент в пользу того, чтобы не экономить на первых этапах.

Модель оплаты влияет на итог не меньше, чем состав работ.

Fixed Price фиксирует объём, цену и срок. Заказчик знает бюджет заранее, риск недооценки лежит на подрядчике. Работает эта модель при одном условии: до фиксации проведена аналитика и требования описаны достаточно подробно, чтобы их можно было зафиксировать. Мы работаем именно так — сначала предпроектный этап, потом фиксированная цена, и заложенный в ней запас покрывает наш собственный риск.

Time & Material — оплата за фактически затраченное время. Гибко и прозрачно, приоритеты можно менять по ходу, но итоговая сумма до конца не зафиксирована. Модель честна там, где требования заведомо будут уточняться: исследовательские продукты, длинные проекты с гипотезами, развитие уже работающего сервиса.

На практике часто работает комбинация. Предпроектный этап оплачивается отдельно и по факту, дальше основная разработка идёт по фиксированной цене, а развитие после релиза — по затраченному времени. Такая схема даёт предсказуемость там, где она нужна заказчику, и гибкость там, где требования всё равно будут меняться.

Чего не существует ни у кого — фиксированной цены при свободе менять требования. Ожидание этого сочетания и порождает конфликты в духе «вы же обещали дешевле». Меняются требования — пересчитывается смета, и нормальный подрядчик показывает пересчёт до того, как начнёт работу.

Сравнивать исполнителей по цене за час — ошибка. Сравнивают по ответственности за результат и по тому, что будет на второй год.

Способов сэкономить много, но большинство из них экономят на том, за что потом платят дважды. Работают четыре.

Сузить первую версию. Самый сильный рычаг. Один доведённый до конца сценарий вместо десяти начатых сокращает бюджет кратно и даёт обратную связь от реальных пользователей. Как определить границу первой версии — в материале про MVP.

Отказаться от второй платформы на старте. Выпустить сначала там, где ваша аудитория, и добавить вторую после проверки спроса. При общей кодовой базе это дешевле, чем кажется.

Использовать готовые решения там, где своё не даёт преимущества. Авторизация, платежи, карты, аналитика — здесь изобретать нечего.

Взять типовое решение целиком, если задача типовая. Для стандартных сценариев быстрее и дешевле выходит приложение под ключ на готовой основе, чем разработка с нуля.

Разбить проект на этапы с отдельными бюджетами. Вместо одного контракта на весь продукт — первый этап с понятным результатом, оценка результата, решение о втором. Так вы платите за следующий кусок, уже видя работу подрядчика, и можете остановиться, если продукт не полетел.

Что не работает: убрать аналитику, отказаться от тестирования, взять команду подешевле на тех же задачах. Все три способа переносят расходы на более поздний этап и увеличивают их. Экономия на аналитике особенно коварна: она не видна в момент подписания и проявляется через два месяца, когда команда третий раз переделывает один и тот же экран.

Разработка — разовая трата. Владение приложением — постоянная, и её закладывают сразу.

Поддержка и развитие. Операционные системы и сторы обновляются минимум дважды в год, устаревают библиотеки, всплывают баги, пользователи просят новое.

Серверы и инфраструктура. Бэкенд где-то живёт, и за это платят ежемесячно. Чем выше нагрузка, тем дороже.

Сборы и комиссии платформ. Аккаунт Apple Developer — 99 $ в год, Google Play — 25 $ единоразово. С продаж App Store берёт 30 % или 15 % по программе для малого бизнеса с оборотом до 1 млн $ в год, RuStore — 15 %, а за платежи мимо своего SDK комиссию не берёт вовсе.

Маркетинг и работа с карточкой в сторе. Приложение, которое не нашли и не установили, не окупится, каким бы хорошим оно ни было.

Сертификаты, домены и внешние сервисы. Push-уведомления, карты, аналитика, отправка писем и SMS — почти каждый такой сервис платный после бесплатного лимита, и счёт растёт вместе с аудиторией.

Работа на вашей стороне. Контент, модерация, ответы пользователям, выгрузка данных из внутренних систем. Эти часы не попадают в смету подрядчика, но они есть, и их стоит посчитать заранее.

Про эту цифру не спрашивают на старте, а именно она определяет, окупится продукт или нет. Структура расходов после релиза выглядит так.

Шесть вопросов, ответы на которые меняют смету сильнее, чем торг по итоговой цифре.

• 1. Что входит в каждую крупную функцию и что в неё не входит?
• 2. Кто отвечает за интеграции и что будет, если чужая система окажется не готова?
• 3. По каким критериям вы будете считать работу выполненной?
• 4. Что происходит с ценой, если требования изменятся в середине проекта?
• 5. Кому принадлежат исходники, документация и аккаунты после оплаты?
• 6. Сколько будет стоить поддержка на первый год после релиза?

Ответ «обсудим в процессе» на любой из шести — сам по себе информация.

Задавать их лучше письменно и всем подрядчикам одновременно. Ответы удобно свести в одну таблицу: разница в подходах видна сразу, а у вас на руках остаётся документ, к которому можно вернуться, когда через полгода начнётся спор о том, что было обещано.

Чтобы смета была про вас, к разговору стоит подготовить суть продукта и ключевой сценарий, список основных функций, нужные платформы, системы для интеграции, ожидания по нагрузке и срокам. Чем полнее вводные, тем у́же конус и точнее цифра.

Отдельно стоит сформулировать, какую цифру бизнеса приложение должно сдвинуть. Это не формальность: под задачу «снять нагрузку с колл-центра» и под задачу «поднять повторные покупки» собираются разные продукты с разной стоимостью, даже если экраны выглядят похоже. Подрядчик, который спрашивает про метрику раньше, чем про количество экранов, экономит вам деньги уже на этом этапе.

Нормальный срок подготовки сметы по внятному описанию — несколько рабочих дней. Мгновенный ответ означает шаблон, а две недели молчания — что вашу задачу отложили.

Ориентир, чтобы разговор начинался не с нуля: мобильное приложение на Flutter мы делаем от 1,8 млн ₽, MVP на одну ключевую функцию — от 1 млн ₽, отдельная интеграция — от 150 тыс. ₽. Это нижняя граница, а не средняя цена: дальше её двигают функции, платформы и требования к нагрузке. Оценка по вашим вводным бесплатная и автоматизированная — загрузите ТЗ в калькулятор или опишите задачу словами, вернёмся со сметой по этапам.

Мы делаем заказные мобильные и веб-продукты со сложной логикой, интеграциями и нагрузкой. Смету собираем по вашим требованиям и показываем, из чего она состоит: какие работы входят в каждую функцию, где заложен резерв и что не входит вовсе.

Фиксируем цену и срок до старта, риск недооценки берём на себя. Команда собрана внутри — аналитика, дизайн, мобильная разработка, бэкенд и тестирование, — а часть рутины в конвейере закрывает AI-first подход, за счёт чего рабочий продукт выходит за 2–3 месяца.

Обсудить проект →