Один из факторов, который сильнее всего влияет на бюджет и почти всегда недооценивается на старте, — выбор между нативной разработкой и кроссплатформенным решением. Разница здесь не только в технологии, но и в том, сколько команд ведёт проект и сколько часов требуется на каждую платформу — а значит, и в итоговой смете разработки.
Нативная разработка — это Swift и Objective-C для iOS и отдельно Kotlin для Android: две кодовые базы, два набора экранов, но зато максимальная скорость работы и полный доступ к возможностям устройства. Кроссплатформенный Flutter позволяет вести один код для обеих платформ сразу — это ощутимо экономит часы на старте проекта.
Для приложения GRAND LINE, каталога для 140 офисов продаж производителя, была выбрана архитектура, которая позволила сократить обновление каталога с недели до часа — а не просто «сделать красивый каталог». Это дало клиенту экономию до 8 млн рублей в год: результат, которого не получить, если экономить на архитектуре ради более низкой стоимости на старте.
Похожий эффект платформенного решения виден и в приложении ProfApp для мастеров и малого бизнеса: онлайн-запись, склад и финансы в одном приложении принесли клиенту рост выручки на 28 % в 2023 году.
Стоимость создания приложения складывается из часов аналитика, дизайнера, разработчиков нужных платформ, backend-специалиста, тестировщика и менеджера — а не из абстрактной «сложности» проекта на глаз.
Мы заранее объясняем, как выбор платформы отразится на бюджете, чтобы решение принималось на основе цифр, а не интуиции. В штате MEN IN DEV все специалисты работают постоянно — аналитики, дизайнеры, iOS- и Android-разработчики, backend, QA и менеджеры, — поэтому в смету не закладываются наценки за поиск и координацию сторонних подрядчиков.
Как платформа влияет на бюджет приложения
Если бизнесу нужно быстро проверить гипотезу на iOS и Android одновременно и бюджет ограничен, Flutter обычно выгоднее: одна команда разработчиков ведёт один код вместо двух отдельных, и это сказывается на количестве часов в смете.
Если приложению предстоит работать с камерой, геолокацией, Bluetooth-устройствами или выдерживать высокую нагрузку, как в ProfApp с учётом склада и финансов в реальном времени, чаще выгоднее нативная разработка — она снимает риски совместимости и добавляет запас по производительности, который сложно получить на кроссплатформенном решении.
Иногда решение комбинированное: часть приложения делаем нативно там, где важна скорость и доступ к «железу», а часть — на общей кроссплатформенной логике, что позволяет не переплачивать там, где особые возможности платформы не нужны. Это тоже решение, которое стоит обсудить на брифинге, а не выбирать по умолчанию, потому что от него зависит и итоговая архитектура, и число часов на реализацию.
Backend для мобильных приложений мы пишем на PHP — он выдерживает нагрузку крупных проектов вроде GRAND LINE, где обновления каталога должны доходить до 140 точек продаж почти мгновенно.
Выбор платформы — это решение не только про бюджет разработки, но и про стоимость дальнейшей поддержки: два нативных приложения обновляются отдельно, требуют отдельного тестирования на каждой платформе и отдельных часов на исправление багов, а кроссплатформенное приложение обновляется одним релизом сразу на обе платформы.
Разработка приложения: бюджет и сроки
Бюджет и сроки связаны напрямую: чем больше функций нужно выпустить к дате запуска, тем больше специалистов работает параллельно. Поэтому мы предлагаем определить, что обязательно должно быть в первой версии, а что можно добавить позже.
MVP с ключевыми функциями позволяет запуститься быстрее и проверить спрос на реальных пользователях, прежде чем инвестировать в полный набор функций и расширенную интеграцию с учётными системами. Кроссплатформенная разработка на Flutter особенно хорошо подходит для MVP, когда приложение нужно сразу на iOS и Android.
После MVP развитие продукта удобнее вести по модели Time & Materials — оплата фактических часов позволяет гибко добавлять функции по мере роста аудитории, как это происходило с ProfApp, где со временем добавились онлайн-запись, склад и учёт финансов.
Для крупных продуктов с самого начала понятной функциональностью подходит Fixed Price — стоимость и сроки фиксируются в договоре, что удобно для бюджетирования на стороне заказчика и снимает риск неожиданных доплат в процессе разработки.
Точную оценку сроков и бюджета мы даём после брифинга, когда понятны платформы, функциональность и желаемая дата запуска.
Стоимость приложения: что учесть на старте
Перед брифингом полезно определиться с несколькими вещами: какая аудитория будет пользоваться приложением, на каких платформах, какие функции обязательны в первой версии, а какие можно добавить позже без переделки архитектуры.
Готовность материалов тоже влияет на бюджет: если у вас уже есть ТЗ, дизайн или работающая веб-версия продукта, часть работ на старте сокращается, а вместе с ней и часы аналитика с дизайнером. Если идея пока на уровне концепции, мы начинаем с аналитики бизнес-процессов и аудитории.
Не стоит закладывать в план только разработку — тестирование, публикация в App Store и Google Play и последующая поддержка тоже часть общей стоимости продукта, а не отдельные «доплаты потом», о которых заказчик узнаёт постфактум. Отдельно стоит учитывать интеграции с 1С, CRM и платёжными сервисами: они часто занимают заметную долю часов, но избавляют бизнес от ручной работы после запуска.
Итоговая цифра зависит от выбранной платформы и технологии, поэтому фиксированного прайса на сайте нет и не будет — стоимость нативной разработки на Swift и Kotlin и кроссплатформенного решения на Flutter мы считаем отдельно под задачу. Заполните форму заявки на сайте: в ней есть поле для описания проекта и можно приложить файл до 50 МБ с макетами или документацией. Если у вас уже готово техническое задание, пришлите его на info@mendev.ru — оценку дадим по нему, без повторного брифинга. На самом брифинге разберём, какая платформа подойдёт вашей задаче, и назовём сроки и стоимость.
