Сколько стоит разработка приложения и почему сметы отличаются в разы

Игорь, основатель Diaverse · 8 октября 2026 · 15 минут чтения

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

Почему на вопрос «сколько стоит приложение» не отвечают одной цифрой?

Главное: приложение — не товар с ценником, а работа людей, объём которой зависит от ваших решений. Полезный ответ — не «зависит», а вилка с условиями: «если так — от A до B, если добавить вот это — вилка сдвигается».

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

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

Из чего складывается цена разработки?

Главное: цена = кто нужен × сколько времени × ставка, плюс запас на риски. Платформа, интеграции, дизайн и инфраструктура влияют на цену через время.

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

Что двигает время, а значит и цену

Если приложение хранит персональные данные пользователей из России, требования 152-ФЗ могут повлиять на выбор хостинга и объём работы. Это не юридическая консультация: такие вопросы лучше обсудить с юристом до оценки.

Как самому прикинуть порядок бюджета?

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

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

Почему сметы на «одно и то же» отличаются в разы?

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

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

• Разное понимание объёма. Один оценил несколько экранов, другой — систему с оплатой и кабинетами (см. пример ниже). Обе оценки могут быть честными, просто это разные проекты.
• Разный состав команды. Один разработчик, который делает всё сам, и команда из менеджера, аналитика, дизайнера, двух разработчиков, тестировщика и DevOps — разная цена одного объёма. Чем больше людей, тем больше времени уходит на координацию.
• Разный запас на риски. Один заложил неизвестное в цену, другой — нет. Вторая смета выглядит привлекательнее, но неизвестное вернётся позже — доплатами или срезанным качеством.
• Разная модель оплаты. Фикс за проект обычно включает плату подрядчика за риск. Почасовая оценка на старте выглядит меньше, потому что риск остаётся на вас.
• Разное качество «под капотом». Прототип, чтобы показать идею, и продукт с тестами, резервными копиями, защитой данных и документацией — это разный объём работы, хотя на демо они могут выглядеть одинаково.

Как состав команды влияет на цену, мы проверили на себе, на примере Diaverse: полтора года назад у Diaverse — нашего собственного мобильного приложения — была классическая команда: проджекты, менеджеры, поддержка, разработчики, дизайнеры. Зарплаты команды составляли $20 000–25 000 в месяц, а двигались мы медленно. Сегодня Diaverse разрабатывается меньше чем за $3 000 в месяц — примерно при том же объёме разработки. Не в каждом проекте получится так же; подробнее — в статье о сокращении затрат на разработку.

Фикс, почасовая оплата или команда помесячно: что выбрать?

Главное: модель оплаты сама по себе не делает разработку дешевле. Она решает, кто платит за изменения и неизвестное и насколько предсказуем ваш счёт.

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

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

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

Как получить оценки, которые можно сравнить?

Главное: всем подрядчикам — один и тот же документ, одни и те же вопросы и одна форма ответа. Тогда разница в сметах становится объяснимой.

1. Опишите задачу на одной странице: кто пользователь, какая проблема, главный сценарий по шагам, что входит в первую версию и что не входит. Как это сделать без технических знаний — в статье о том, как поставить задачу разработчику.
2. Отправьте всем один и тот же текст. Если в переписке вы рассказали кому-то больше, допишите это в документ и разошлите всем заново.
3. Попросите ответ в одном формате: этапы, роли и время на каждый этап, допущения, что не входит в оценку, вилка «от и до» и что сдвигает оценку к верхней границе.
4. Задайте всем одинаковые вопросы из чек-листа в конце статьи.
5. Сравнивайте не итог, а строки. Где один заложил неделю, а другой месяц, там разное понимание задачи — его и нужно обсудить.
6. Обсудите крайние оценки. Спросите автора самой низкой, что он не заложил, а автора самой высокой — за что именно вы платите.

Ещё один сигнал — встречные вопросы. Тот, кто уточняет сценарии, роли пользователей и интеграции, оценивает ваш проект. Тот, кто называет цену без единого вопроса, скорее всего оценивает свой типовой. Как выбрать и проверить исполнителя до оплаты — в статье о выборе подрядчика.

Сколько приложение стоит после запуска?

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

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

• Хостинг, база данных и домен. Серверы, хранение файлов, резервные копии. Растут вместе с числом пользователей и объёмом данных.
• Платные сервисы. SMS и рассылки, push-уведомления, карты, аналитика. Многие бесплатны до порога, а дальше тарифицируются по объёму.
• Магазины приложений. Участие в Apple Developer Program стоит 99 USD в год (цена может отличаться по региону), аккаунт разработчика Google Play — разовый взнос 25 USD; данные страниц Apple и Google на октябрь 2026. С продаж цифровых товаров и подписок внутри приложения магазины берут комиссию, размер зависит от программы и оборота — см. правила Apple и Google Play.
• Приём платежей. Платёжный сервис берёт комиссию с каждого платежа на сайте или в веб-версии.
• Запросы к ИИ. Каждый запрос к модели стоит денег, и счёт растёт с числом пользователей и длиной текстов. Нужны лимиты, защита от спама и понятный ответ, сколько стоит один типовой запрос.
• Поддержка и обновления. Исправление ошибок, обновление библиотек, совместимость с новыми версиями iOS и Android. Даже без новых функций приложение нужно время от времени обновлять.

До старта попросите подрядчика расписать эти расходы: какие сервисы будут платными, на кого оформлены, сколько продукт будет стоить в месяц при 100, 1 000 и 10 000 пользователей. Достаточно порядка цифр, но с расчётом, а не «там копейки».

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

Как уменьшить стоимость без потери качества?

Главное: дешевле — значит делать меньше, а не хуже. Самая большая экономия — в том, что вы решили пока не строить.

• Проверьте спрос до разработки. Месяцы работы над продуктом, который никому не нужен, — самая дорогая ошибка. Многое можно проверить до первой строчки кода: как — в статье о проверке спроса на идею приложения.
• Сузьте первую версию до одного главного сценария. Что пользователь должен сделать, чтобы получить пользу? Остальное — во вторую очередь: что добавлять, подскажут первые пользователи.
• Начните с одной платформы. Веб-версия или Telegram Mini App часто позволяют проверить продукт без двух мобильных приложений сразу.
• Берите готовое там, где оно есть. Вход в аккаунт, оплата, рассылки, админка — для этого есть готовые сервисы и модули. Спросите подрядчика прямо, что можно взять готовым; иногда честный ответ — «вам хватит конструктора». В нашей выборке 21 сообщение от людей, которые не понимают, хватит ли им готового решения. Если прототип уже собран на конструкторе или с ИИ, разберитесь, когда этого хватает, а когда нужна разработка.
• Сделайте дизайн первой версии на готовых компонентах. Аккуратно и понятно, без уникальных анимаций. Собственный стиль можно добавить, когда станет ясно, что продукт нужен.

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

Частые ошибки

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

Что делать, если смета уже растёт?

Главное: прежде чем платить следующую доплату, разберитесь, откуда берётся рост.

1. Попросите письменно сравнить исходную оценку с текущей: какие задачи добавились, какие оказались больше, чем думали, и почему.
2. Разделите рост на три части: новое, о чём попросили вы; недооценка подрядчика; исправление ошибок в сделанном. При фиксе вторая и третья части обычно не ваш расход — посмотрите договор. Это не юридическая консультация.
3. Заморозьте новые функции до выхода главного сценария к пользователям и перейдите на оплату по этапам с итогом, который можно открыть и проверить.
4. Проверьте, что код и доступы у вас: репозиторий, хостинг, домен, аккаунты магазинов и сервисов.
5. Позовите независимого разработчика на несколько часов посмотреть код и оценки. Обычно это дешевле, чем ещё один месяц доплат.

Если ситуация не меняется, пора думать о смене команды. Как сделать это без переписывания с нуля, разобрано в статье о том, как сократить затраты и передать проект.

Чек-лист: какие вопросы задать про цену

Подрядчик, который спокойно отвечает на эти вопросы, понимает, что продаёт. Если ответы уклончивые, лучше узнать это до предоплаты.

Читайте также

• Как поставить задачу разработчику, если вы не технарь: ТЗ на одной странице
• Как выбрать подрядчика для разработки и не потерять предоплату
• Как проверить спрос на идею приложения до разработки
• Словарь заказчика: MVP, ТЗ, деплой и другие слова простым языком