Code Pilots 
Тендеры и лиды
Информация
Вопрос «сколько стоит разработка мобильного приложения» почти всегда получает честный и бесполезный ответ: от нескольких сотен тысяч до десятков миллионов. Проблема в том, что разброс реальный. Компания рассылает одно описание пяти студиям, получает пять смет, и крайние отличаются втрое.
Дальше начинается неприятное. Кажется, что кто-то жадничает, кто-то демпингует, а как проверить — непонятно. Правда скучнее: студии посчитали разные объёмы работ, и каждая по-своему права.
Я смотрю на это с двух сторон. Как подрядчик в Code Pilots считаю такие сметы двенадцать лет. Как заказчик однажды посчитал сам: свой продукт Hubstr по моим прикидкам стоил миллион, а обошёлся во много раз дороже. Разница сидела ровно в тех строках, которые я в собственной смете не увидел.
Ниже — из чего складывается стоимость разработки мобильного приложения, в каких строках прячется кратная разница и какие вопросы задать, чтобы сравнивать сопоставимые вещи. Конкретных сумм здесь не будет: они зависят от ставки команды, города и состава работ. Структура сметы у всех похожая, и именно в ней видно, за что вы платите.
Когда заказчик рассылает описание на две-три страницы, каждая студия достраивает недостающее сама. Одна прочитает «личный кабинет» как экран с профилем и историей заказов. Вторая — как раздел с ролями, правами, выгрузками и восстановлением доступа. Обе напишут в смете строку «Личный кабинет», и обе не соврут.
Поэтому первый шаг — не сравнивать итоговые суммы, а вытащить из каждого предложения состав работ. Если в коммерческом предложении нет списка экранов и списка того, что система умеет делать, сравнивать пока нечего: вы держите два числа, посчитанных для разных задач.
Самая недооценённая строка. У одних это несколько встреч и описание функций, у других — интервью с теми, кто будет работать в системе, разбор текущих процессов, схема данных и кликабельный прототип до дизайна.
Вторая версия дороже на старте и дешевле в сумме. Функция, которую переделывают после релиза, обходится в несколько раз дороже той, что поймали на прототипе: к цене самой переделки добавляются дизайн, тесты, релиз и объяснения пользователям.
Как проверить строку: спросить, что физически будет на выходе этапа. Ответ «список функций» — это одна работа. Ответ «кликабельный прототип, схема данных и описание ролей» — совсем другая.
Здесь прячется самая большая разница в цене. Заказчик считает экраны, разработка считает состояния.
Один экран каталога живёт в пяти разных видах. Он показывает загрузку, потом нормальный список, потом пустой результат, если ничего не нашлось, потом ошибку сети, потом конец списка. Для экрана оплаты добавляется отказ банка, повтор платежа и возврат из внешнего приложения. Нарисовать красивую картинку с товарами — час. Довести её до состояния, когда приложение не выглядит сломанным в метро на слабом телефоне, — несколько дней.
Смета, в которой написано «12 экранов», и смета, в которой написано «12 экранов, состояния и обработка ошибок», — это разные вселенные. Отсюда чаще всего и берётся кратность.
Первый вариант — нарисовали те экраны, которые перечислены в задании. Второй — дизайн-система, где собраны компоненты и правила, по которым следующие экраны выходят быстрее и дешевле предыдущих.
Набор макетов дешевле, пока экранов мало. На втором десятке он начинает мстить: каждый новый раздел рисуется заново, кнопки в разных местах разъезжаются, правка в одном месте ломает соседнее. Если продукт живёт дольше года, дизайн-система окупается.
Строка «бэкенд» может означать «напишем серверную часть» или «подключимся к вашему API». Разница огромная, а формулировка в коммерческом предложении часто одна.
Если серверная часть уже есть, но её писали под сайт, а не под приложение, появляется третий вариант — доработка чужого кода. Он непредсказуемее обоих: пока не заглянешь внутрь, честной оценки не бывает. Нормальная практика — считать такую работу после короткого платного аудита.
Интеграция с одной системой и «интеграция с учётной системой» в единственном числе — разные вещи. У каждой связки свой объём работ. Свои поля, свои справочники, свой формат ошибок и свой ответственный на той стороне, с которым придётся договариваться отдельно.
Отдельно проверьте, входит ли в цену то, что случается после запуска обмена: разбор непрошедших документов, сверка, поведение при недоступности другой системы. Что входит в такую работу, разобрано в нашем материале об интеграции с 1С.
Тестирование в смете либо стоит отдельной строкой, либо «входит в разработку». Второе обычно означает, что разработчик проверил свою задачу на своём телефоне.
Реальная работа выглядит иначе. Команда пишет сценарии, собирает набор устройств и версий и перед каждым релизом прогоняет регресс. На трёхлетнем Android с тремя гигабайтами памяти приложение ведёт себя иначе, чем на свежем флагмане, и узнать об этом лучше до релиза.
Строка, которую чаще всего просят убрать. За ней стоит человек, который держит план, сводит дизайн с разработкой, ловит расхождения в требованиях и отвечает за срок.
Убрать её можно — работа никуда не денется, её будет делать заказчик. Это рабочий вариант, если у вас есть свой менеджер и он готов тратить на проект несколько часов в день. Решите это до старта: на второй неделе такая экономия превращается в сюрприз.
Три вещи, которых часто нет ни в одном из сравниваемых предложений:
Публикация в магазинах приложений. Аккаунты разработчика, ревью, отклонения и повторные отправки. Сами сборы небольшие (Apple берёт 99 долларов в год, Google — 25 долларов единовременно, RuStore бесплатно), а вот время на ревью и правки по замечаниям считать нужно.
Гарантия. Сколько месяцев и что именно чинят бесплатно — свои ошибки или любые проблемы.
Поддержка. Что происходит, когда через месяц обновится операционная система или сменится API у платёжного провайдера.
Если расставить факторы по силе влияния, порядок получается такой.
Количество платформ. iOS и Android удваивают почти всё, кроме общей логики. Кросс-платформенная разработка снимает большую часть этой надбавки, но тестирование, магазины и правки остаются в двух экземплярах.
Число и сложность интеграций. Каждая внешняя система добавляет не только код, но и переговоры, доступы, тестовые контуры и разбор ошибок.
Роли и права. Приложение с одной ролью и приложение, где закупщик формирует заказ, а руководитель его утверждает, — разная работа при одинаковом числе экранов.
Требования к нагрузке и скорости. Пока пользователей тысячи, архитектура простая. Когда речь о пиках и сезонах, появляются очереди, кеши и нагрузочное тестирование.
Готовность материалов на вашей стороне. Тексты, фотографии, каталог, доступы к системам. Это редко попадает в смету и почти всегда попадает в срок.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Не нужно быть техническим специалистом, чтобы сравнить предложения честно. Достаточно задать каждой студии одни и те же вопросы и записать ответы рядом:
Сколько экранов вы посчитали и учтены ли их состояния — загрузка, пустой список, ошибка?
Что попадает в аналитику и что будет на выходе этого этапа?
Серверную часть пишете вы или цена посчитана под наш готовый API?
Каждая интеграция посчитана отдельно? Что делаете, когда система на той стороне не отвечает?
Тестирование входит в цену? На каких устройствах и сколько регрессов до релиза?
Что входит в гарантию, сколько она длится и что считается гарантийным случаем?
Кому принадлежит код и когда мы его получаем?
Часто выясняется, что дорогое предложение и дешёвое отличаются не подходом, а тем, что во втором половина работ вынесена за рамки. Её всё равно придётся оплатить — позже и отдельным счётом.
Срок врёт чаще цены. Проверять его стоит по трём точкам.
Первая — когда вы увидите работающий продукт, а не картинки. Если первая демонстрация обещана на третьем месяце, это повод насторожиться: нормальный ритм — работающая сборка каждые две недели.
Вторая — что делает команда, пока ждёт от вас ответа. На любом проекте бывают паузы. Ждут согласования, ждут доступы, ждут данные. Хорошо, когда в плане видно, чем эти окна заполняются.
Третья — заложено ли время на приёмку и правки после неё. Если план заканчивается словом «релиз», значит, две недели правок по итогам приёмки живут в воображении.
Соберите из обоих предложений общий список работ — выпишите в столбик всё, что упомянуто хоть где-то. Отметьте, что есть у одного и отсутствует у другого. Как правило, после этого кратность превращается в понятную разницу: у одного посчитана аналитика и тестирование, у другого нет.
Попросите обе студии посчитать одинаковый состав работ. Это нормальная просьба, и по реакции на неё тоже многое видно.
И последнее: сравнивайте не только цену первого релиза. Приложение живёт годами, и решения, принятые на старте, определяют стоимость каждого следующего года. Мы ведём сайт Радиоэлементов с 2014 года, а приложение PetShop — больше десяти лет; в такой перспективе сэкономленные на старте проценты выглядят иначе.
Способ, который работает, — сузить первый релиз до состава, который проверяет главную гипотезу, и дальше развивать продукт итерациями. Как мы собираем такие первые версии, описано на странице разработки MVP.
Второй способ — начать с маленького оплаченного шага: аналитики или прототипа. За две-три недели видно всё: как студия задаёт вопросы, как считает, что происходит при первых расхождениях. И оценка после такого шага опирается на факты.
Третий способ обычно не приходит в голову заказчику — спросить, что у студии уже готово. Авторизацию, роли, платежи, выгрузки и каркас мобильного приложения на типовом проекте редко пишут с нуля. Мы собрали такую библиотеку за годы и добавили к ней AI-инструменты на генерацию кода, тестов и документации — на одном и том же задании это снимает около половины часов. Спросите прямо, что из вашего списка у подрядчика уже написано и проверено в бою: цифра в смете после этого вопроса меняется чаще, чем после торга. Как это устроено у нас — на странице мобильной разработки.
От чего вообще зависит цена приложения? От количества платформ, числа экранов вместе с их состояниями, сложности серверной части и интеграций, требований к нагрузке и готовности ваших материалов. Методы, которыми считают смету, разобраны в материале об оценке стоимости разработки.
Почему студия не называет цену сразу? Потому что до разбора задачи цифра будет выдумана. Честный ответ на первом звонке — диапазон и список того, что нужно уточнить, чтобы диапазон сузился.
Дешевле сделать одно приложение на двух платформах? Обычно да, если продукт не требует тяжёлой работы с железом телефона. Экономия идёт на разработке, но тестирование, публикация и правки остаются двойными.
Что можно не делать в первой версии? Административную панель, настройки, вторую платформу, сложные сценарии оплаты. Не откладывают разметку событий и обработку ошибок — без первого нечем мерить результат, без второго продукт выглядит сломанным.
Сколько стоит поддержка после запуска? Считается отдельно от разработки и зависит от того, что входит в SLA. Минимум, который стоит заложить, — обновления под новые версии операционных систем и реакция на сбои у внешних сервисов.
