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

Вы пришли за цифрой. Большинство статей её дадут — какую-нибудь «вилку от 500 тысяч до 40 миллионов», в которой границы отличаются в восемьдесят раз. Эта цифра бесполезна, и сейчас станет понятно почему: спросить «сколько стоит приложение» — то же самое, что спросить «сколько стоит дом». Землянка и особняк — оба «дом», и любой, кто назовёт вам сумму, не спросив про этажи, материалы и участок, либо гадает, либо продаёт.

Code Pilots считает мобильные проекты каждую неделю, и точную цену мы называем быстро — но после короткого брифа, а не по телефону вслепую. Поэтому здесь не будет прайс-листа. Будет кое-что полезнее: разбор того, из чего цена складывается, что её двигает, как студии вообще оценивают трудозатраты и как читать чужую смету, чтобы не переплатить. После этого вы сможете прикинуть бюджет любого приложения сами — и будете морщиться, встречая в интернете очередную «среднюю цену».

«Сколько стоит приложение» — неответимый вопрос в той же мере, в какой неответим вопрос «сколько стоит автомобиль». И дело не в нежелании отвечать, а в том, что под одним словом скрываются принципиально разные вещи.

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

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

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

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

Число платформ. Две нативные разработки, отдельно под iOS и Android, — это два проекта и двойной счёт. Одна кроссплатформа на Flutter покрывает обе платформы из общего кода и экономит ощутимую долю бюджета, особенно на поддержке (одну кодовую базу дешевле сопровождать, чем две). Это не компромисс по качеству, а способ убрать дублирование, и для большинства задач он и определяет экономику проекта.

Сложность функций. Дело не в количестве экранов, а в логике за ними. SMS-вход и каталог — это одно. Чат с видеозвонками, рекомендательная система, AR или офлайн-синхронизация — каждая такая функция тянет недели работы и собственные риски. «Добавим ещё чат» — это не строчка в смете, а сдвиг сроков.

Интеграции — главный скрытый множитель. Оплата, CRM, 1С, карты, складские и чужие системы. Каждый внешний сервис — это чужой API со своими лимитами и отказами, который проектируют и тестируют как полноценную часть продукта. Недооценка интеграций — самая частая причина, почему смета «вдруг» вырастает по ходу.

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

Глубина дизайна. Интерфейс на стандартных компонентах и проработанный UX с собственным стилем, анимациями и дизайн-системой — разные бюджеты.

Сроки. «Нужно вчера» всегда дороже: сжатые сроки требуют больше людей параллельно и съедают эффективность.

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

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

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

Story Points и Planning Poker. В гибких командах оценивают не часы, а относительную сложность задач в условных баллах — так точнее, потому что человек плохо угадывает абсолютные сроки, но хорошо чувствует, что одна задача вдвое сложнее другой. Скорость команды (сколько баллов закрывается за спринт) со временем превращает баллы в сроки.

Трёхточечная оценка (PERT). Для каждой задачи дают три оценки — оптимистичную, реалистичную и пессимистичную — и выводят взвешенную. Это честно отражает, что у любой задачи есть разброс.

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

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

В адекватной смете есть: разбивка по этапам (аналитика, дизайн, разработка, тестирование, публикация) и по ролям, понятный список того, что входит и что НЕ входит, и заложенный резерв на непредвиденное.

Красные флаги:

• Смета одной строкой «разработка приложения — N». Это не оценка, а число с потолка: непонятно, что внутри.
• «Всё включено по фиксированной цене» без оговорок. Либо в фикс зашита большая подушка (вы переплатите), либо половину работ в него не положили (узнаете в процессе).
• Нет аналитики и тестирования в составе работ. Их не «сэкономили» — их просто переложили на вас в виде будущих переделок.
• Ставка и сроки «как у всех» без привязки к вашим требованиям. Признак, что проект не разобрали, а подставили в шаблон.

Отдельно стоит различать «дёшево» и «недооценено». Дёшево — это когда подрядчик сознательно работает по низкой марже или урезал понятный объём. Недооценено — когда он не разглядел сложность (чаще всего в интеграциях и нагрузке) и назвал цифру, которую не вытянет. Второе опаснее первого: такой проект либо встанет на середине, либо превратится в поток допсоглашений. Самое дешёвое КП на старте регулярно оказывается самым дорогим в финале — просто доплачиваете вы потом и, нередко, уже другому подрядчику.

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

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

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

Главное, чего не существует ни у кого, — «фикс цены при свободе менять требования». Именно ожидание этого мифического сочетания и порождает конфликты «вы же обещали дешевле».

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

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

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

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

Сборы и комиссии сторов (единственные точные числа в этом материале — и они не наши, а платформ): аккаунт Apple Developer — 99 $ в год, Google Play — единоразовые 25 $. С продаж сторы берут комиссию: App Store — 30% (или 15% по программе для малого бизнеса с оборотом до 1 млн $ в год), RuStore — 15%, со снижением через собственный платёжный шлюз. На обороте эта разница напрямую влияет на вашу выручку, поэтому её прикидывают ещё на этапе планирования монетизации.

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

Чтобы смета была про вас, а не «средняя по рынку», к разговору с подрядчиком полезно подготовить: суть продукта и ключевой сценарий, список основных функций, нужные платформы, системы для интеграции (оплата, CRM, 1С), ожидания по нагрузке и срокам, наличие готового дизайна или бренда. Чем полнее эти вводные, тем у́же конус и точнее цифра.

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