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

    Всем привет, меня зовут Сева, я директор проектного управления в Citronium. Все мои друзья, кто так или иначе связан с бизнесом постоянно задают мне два вопроса: “Сколько стоит сделать мобильное приложение? Ну такое, чтоб прям нормальное было. Стандартное, но не очень дорогое.” и “А почем нынче вебсайты? Ну такие, стандартные, как у всех”.

    Я поначалу отвечал невнятно, говорил, что все всегда по-разному, а тут все же сам задумался над обоими вопросами и решил на них ответить. По порядку. Начнем с мобильного приложения. Я посчитал среднюю стоимость каждого этапа разработки всех составляющих мобильного приложения и получил примерные цифры. Если коротко, это порядка 1.5 млн рублей за гибридное мобильное приложение и порядка 2.2 млн рублей за два нативных приложения, то есть одно под Android и еще одно под iOS.

    Ничесе. А че так дорого?


    Для кого-то это большие деньги, для кого-то — нет, но в целом это недорого, это столько стоит. Давайте обо всем по порядку.

    Разработка “ну такого, нормального” мобильного приложения (да и веб-продукта тоже) состоит из четырех-пяти этапов, в основном пяти:

    1. Предпродажа и бизнес-аналитика.
    2. Подготовительный этап.
    3. Разработка.
    4. Завершение проекта, публикация приложений.
    5. Дополнительная разработка (по необходимости).

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

    Итак, давайте подробнее о каждом из этапов.

    Предпродажа и бизнес-аналитика


    Этот этап условно-бесплатный (он стоит порядка 80 тыс. рублей). За него заказчик заплатит только в том случае, если выберет нас подрядчиками на свой проект. Мы формируем видение проекта в формате майнд мапа, где определяем основных стейкхолдеров проекта и их ожидания, здесь же анализируем целевую аудиторию будущего приложения, исследуем схожие или аналогичные решения конкурентов и как итог получаем структуру будущего мобильного приложения, а еще панели администрирования к нему.

    Здесь очень важно заметить, что мобильному приложению часто (90% случаев) нужна админка — веб-приложение, что, естественно, делает разработку дороже.



    После составления интеллект-карты структуры проекта, мы беремся за техническое решение и кликабельный прототип будущего приложения (пока без дизайна). Техническое решение включает в себя: структуру БД, исследование и выбор нужных для разработки библиотек, изучение стороннего API, которое потребуется подключить и формирование диаграммы контекста проекта. Прототип включает в себя прототип. На основе двух этих артефактов мы даем контурную оценку проекта (от и до) и предоставляем заказчику соответствующие сметы. Если с нами соглашаются работать дальше, то стоимость этапа бизнес-аналитики включается в стоимость проекта, если не соглашаются — что ж, это наши риски.

    Подготовительный этап


    Дизайн + подготовка к развертыванию проекта, формирование документационной базы для мобильного приложения и для системы управления контентом — панели администрирования (в среднем 100 тыс. рублей).

    Мы продумываем UX приложения, составляем Customer Journey Map (CJM) и User Flow, начинаем писать пользовательский гайд к приложению. Рисуем UI, в соответствии с пожеланиями/брэнд-буком заказчика и проходим множество согласований дизайна.

    Параллельно работаем над архитектурой проекта и описанием его сущностей. Здесь дополняются и появляются следующие артефакты:

    • Контекстная диаграмма
    • Диаграмма контейнеров
    • Диаграмма классов
    • Отношения сущностей
    • Файл с описанием сущностей БД (таблицы сущностей)




    Дизайн готов, архитектура готова — настраиваем серверную инфраструктуру, репозитории и сборки (CI/CD) и начинаем кодить.

    Разработка


    Разрабатываем приложения в соответствии со всеми правилами гибкой разработки (1.3 млн рублей). Постоянно держим заказчика в курсе событий, регулярно (еженедельно, но на старте проекта раз в 2 недели) показываем результаты работ, оперативно вносим исправления и устраняем баги. Учитываем пожелания заказчика, которые появляются в процессе работы, берем за них доплату, либо убираем из планов что-то из старых хотелок.

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

    Разработка — самый долгий этап, он зачастую разбит на много спринтов, и промежуточных этапов, после завершения которых мы получим часть денег. Если говорить про “ну вот такое простое приложение” (и админку к нему), то это 30% предоплаты (400 тыс. рублей) + промежуточный и финальные платежи в 35% (450 тыс. рублей), если речь идет о гибридном приложении. С двумя нативными соотношение примерно такое: 600 тыс. рублей. + 700 тыс. рублей + 700 тыс. рублей.

    Завершение проекта, публикация приложений


    20 тыс. рублей на оплату аккаунтов Apple и Google Developer. Выкладка приложений, ревью от сторов и вуаля — приложение в лайве и доступно для скачивания.



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

    Дополнительная разработка


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

    О чем еще нужно знать


    В первую очередь, о расходах на содержание облачных сервисов. Если клиент из России, то скорее всего это будет Яндекс.Облако. Первые два месяца содержание не будет стоить ничего, потому что так решил Яндекс (он предоставляет небольшой грант), а потом сервер будет обходиться от 2.5 тыс. рублей (иногда значительно больше) в месяц, в зависимости от подъемности/неподъемности приложения.

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

    В общем и целом, разработка это недешево, но это действительно столько стоит, а иногда и гораздо больше.

    Комментарии 37

      +2

      А если приходит клиент со словами вот вы делали приложение кушайпиццу, мне тоже самое только лого поменяйте и цвет. Тоже будет стоить так же?

        +3
        Зависит от договоренностей с предыдущим заказчиком и контракта, по которому работали. В целом, будет дешевле, потому что какая-то логика будет переиспользована, но весь код мы переиспользовать не сможем и технически это будет не просто поменять цвет и лого.

          +2

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

            0
            Разве с мобилками такое есть? Мне кажется это противоречит маркетплейсам — насыщение копипастой.
              0
              Всё зависит от качества коробочного решения, и полезности приложения на котором сделано решение.
              +1
              Именно, по сути это уже продажа продукта, нежели разработка приложения под заказ. Есть компании, которые живут на этом: Loyalty Plant, например.
                0
                Например, решение для пиццерий. Работайте по нашей бизнес модели. И фигачить общую кодовую базу, с ветками для компиляции только разных переменных цвета и логотипов.
                Ага выше увидел про Loyalty Plant.
              0
              Я думал гибридное будет минимум в два раза дешевле стоить, а разница оказывается не такая большая.

              Флаттер не рассматриваете? Довольно любопытная штучка. Если сейчас багу мою смогу поправить с помощью разрабов, то сложная интеграция с существующей нативной кодовой базой (наверное, самое сложное это типа OCR движока нативного) то можно считать вполне готовым продуктом для прода. Без этого и подавно.
                0
                Для студий стоимость состоит из оплаты работы участников команды + прибыль для самой студии. Поэтому озвученный порядок более/менее правильный.
                Частные разработчики обходятся дешевле в несколько раз за аналогичный проект, т.к. оплата требуется только за их работу (прибыль уже включена в оплату). За проект средней сложности 150-250 т.р…

                Аргумент студий, что «они не исчезнут» и «всё сделают до конца» в «отличие от частных разработчиков» не работает. Не исчезают, но разработка может просто затормозиться, студия начинает «кормить завтраками», в итоге готового приложения нет.
                  +1
                  Разные бывают фрилансеры и разные бывают студии. Тут сложно сказать «все фрилансеры делают хорошо и в 10 раз дешевле», а «все студии сильно завышают цены», но в чем вы абсолютно правы, так это в том, что студии действительно стоят дороже. Да и юридически с ними куда проще, чем с фрилансерами, в случае чего.

                  К сожалению, студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
                    +1
                    юридически с студиями куда проще, чем с фрилансерами, в случае чего.
                    студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
                    Это не вопрос фрилансера и студии, а вопрос размера заказчика и исполнителя. Чем больше перевес по размерам в пользу одной из сторон — тем юридически этой стороне проще, в том числе и с кормлением завтраками.
                    Фрилансер тут играющий роль и юриста и продажника, при этом не являющийся профи ни в одной из этих областей, будет низшим звеном в этой пищевой цепочке, поэтому в целом клиенту с юридической точки зрения (продавить свои условия) и с точки зрения завтраков (динамить с выполнением своей части) и т.д. — будет проще с фрилансером, а не со студией.
                    В свою очередь редко какая студия сможет что-то позитивное для себя получить в юридичеком смысле в договоре, скажем, с лукойлом. Хотя обычного физика клиента она своим, хоть и небольшим, юр. штатом размажет по стенке.
                      0
                      вопрос размера заказчика и исполнителя
                      весьма точное замечание, причем работающее в обе стороны. Ведь есть не только фрилансеры-исполнители, но и мелкие заказчики, для которых бюджет проекта в 1.5 млн на их текущем этапе неподъёмен.
                        0
                        Да, вы правы, есть и такие заказчики. И вопрос в том, насколько меньше их бюджет, обозначенной суммы и что им нужно за эту сумму сделать. Если функциональные требования и бюджет соотносимы, то студия может работать с таким клиентом. Если же не соотносимы: то есть требований на 1.5 млн, а бюджета 500 тыс., то тут каши не сварить и скорее всего заказчику придется искать фрилансера, который не обременен всеми ценообразующими факторами студии.
                        0
                        Если в сотрудничестве у кого-то есть цель размазать другую сторону по стенке — это плохое сотрудничество. Крупность той или иной стороны лишь усиливает бюрократизацию всего процесса, но в то же время бюрократизация может быть гарантом. С фрилансерами меньше бюрократии и меньше гарантий, со студиями больше, но это не говорит о том, что не надо работать с фрилансерами, надо работать со студиями. Вовсе нет, все индивидуально. Есть крутые студии и плохие фрилансеры, но есть и плохие студии и крутые фрилансеры. Тем не менее, заключая договор со студией вы минимизируете свои риски, а договариваясь с фрилансером зачастую увеличиваете их.
                          0
                          Если в сотрудничестве у кого-то есть цель размазать другую сторону по стенке — это плохое сотрудничество.
                          Абсолютно любой бизнес составляет договор в свою пользу, с подстраховкой себя. Никто не составляет договор в пользу другой стороны.
                          При этом одни и те же пункты в своем договоре будут названы «защитой своих интересов», а те же в чужом договоре назовут «включенными с целью размазать по стенке»:)

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

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

                          Как правило всё как раз наоборот, просто по объективным причинам — уровень юр.грамотности у фрилансера заведомо ниже уровня студии. То что придумает включить в договор студия и что она туда не пропустит — фрилансеру, в меру его непрофильности в юридической сфере и в голову не придет.
                    0
                    Кроме приложений есть еще сервер и админка, поэтому в полтора раза дешевле, да и нативку поддерживать выходит дешевле. Гибрид, как показывает практика, ломается чаще, и не потому что мы плохо сделали, а потому что среда меняется постоянно. Обновился iOS — обязательно что-нибудь фиксим. То же самое с Android.

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

                    Интересно посмотреть, можете ссылку на ваш гитхаб дать?
                      0

                      Кстати, может, напишете статью про "обновилось — фиксим"? Очень интересно, что приходится переписывать, что чинить, что ломается обновлениями.

                        +2
                        Если коротко, сломаться может все что угодно. Где-то может верстка поплыть, где-то картинки в принципе не отобразятся, собьются настройки приложения по умолчанию и т.д. Влияет не только обновление ОС, но еще и обновление API сторонних сервисов, которые используем.

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

                        Интересная, кстати, идея — собрать список наиболее распространенных проблем и оформить их в статью. Как-нибудь займусь этим, спасибо.
                      0
                      Сева, добрый день.
                      Вы пишите: «в соответствии со всеми правилами гибкой разработки». Как я понял разработка через аутсорс.
                      Подскажите, как вам удается поддерживать комманду в виде единого, зрелого юнита, чтобы прогнозировать сроки проекта (например с помощью BurnDown Chart). Или заказчик не требует сроки?
                        0
                        Добрый день, в основном это диаграмма Гантта. И таблица статусов готовности функционала — по сути бёрндаун в табличном виде. Ну и плюс мы постоянно показываем, что мы сделали, то есть заказчик в любой момент может зайти на dev окружение, посмотреть как дела на вебе или запросить у нас промежуточный билд приложения: iOS передадим через TestFlight, Android — через Firebase.

                        Конечно, заказчик требует сроки, да и это в наших интересах в них уложиться: мы не получим деньги, пока не достигнем оговоренного майлстоуна. :)
                        –3

                        Все это, имхо, надуманная величина. Это как с сайтами. На заре их делали за очень большие деньги. И дело не в сыистоперлелках, а в том, что в ту пору элкюектронная коммерция была еще неведомой… и в основном это был поиск пути. Но потом, накопился опыт. И этих ваших cms миллионы. И написано к ним миллионы миллионов модулей.
                        И все, как оказалось, легко стандартизируется. Тут на арену вышел маркетинг в полной красе. Ибо надо обосновать мегабюджеты на новую лого картинку.
                        Сегодня "стандартный сайт" со стандартным интернет магазином и т.д. Есть на любой вкус.
                        То же самое и с мобильной разработкой.
                        Чем отличается зимняя рыбалка от летней? Да ничем. Наливай и пей.
                        Так и тут. Всё, что дрступнл на сайте доступно и в мобилке. Весь функционал любого приложения — стандартен.
                        Да. Есть нюансы, кастомизации. Ео 90% всего будет остального одинаково.

                          +3
                          Было бы очень здорово, если бы все было так просто. :)
                            +4
                            Весь функционал любого приложения — стандартен.

                            Может в мире реселлеров с али-экспресса и доставок пиццы это и так, но в мире IT-бизнеса все ровно наоборот. Если у Вашего нового сервиса / приложения все тоже самое, что и у конкуретнов, то с какой стати пользователь пойдет к Вам, а не к ним?

                              0
                              Абсолютно точно.
                              +3

                              Приложение магазин, приложение 3д вьювер редактор, приложение для биржи, приложение мессенджер, что между ними такого общего что их можно было бы из одинаковых модулей собирать?

                                –1

                                как минимум, аутентификация пользователя.

                                  +2
                                  Аутентификацию частично тоже приходится писать заново, как минимум потому что у каждого приложения свой сервер, а вообще аутентификация бывает разной:
                                  — по email
                                  — по номеру телефона
                                  — через соц. сети
                                  — и т.д.

                                  Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
                                    +1
                                    Аутентификация в разных приложениях требует разной степени защиты, некоторые при каждом входе требуют аутентификацию через Google Authenticator., а приложение сканер сети — на кой ему аутентификация?
                                    В большинстве случаев однотипные приложения можно собирать из одинаковых модулей, но и только.
                              0
                              Вот если бы такую-же статью, но на конкретном примере, как ответы въедливому заказчику: «на что ушло время? почему это было необходимо? и сколько оно стоило?», было бы более познавательно. )
                                +1
                                Если описывать конкретный пример, то можно засветить очень много ндашной информации, но в следующий раз попробую написать конкретнее, спасибо за комментарий. :)
                                  0
                                  Ответное спасибо за статью, даже общее описанием этапов и порядок цен было тоже полезно узнать.
                                    0
                                    Если у вас будет проект — пишите, оформим конкретный кейс. :)
                                +1
                                Сева, спасибо за статью. Теперь буду скидывать её моим знакомым, которые тоже задают подобные вопросы :)
                                  0
                                  Очень рад слышать, что вы нашли статью полезной!
                                  0
                                  Отличная статья. Благодарю.
                                  Теперь знаю как просветиться заказчика.
                                    0
                                    Благодарю. Очень рад слышать, что статья в том числе решает менеджерские боли.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое