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

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

До заказа нужно определить:

• кто будет пользоваться продуктом;
• с какими системами он должен обмениваться данными;
• как оценивать результат после запуска.

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

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

1. Опишите пользователя и действие, ради которого он открывает приложение. Для доставки это выбор рациона и оформление заказа, для языковой школы – выполнение упражнения. У сотрудника выездной службы другой сценарий: получить задание, приложить фотографии и передать результат.
2. Проверьте действующий процесс. Сколько времени он занимает, какие действия повторяются и где люди обращаются за помощью? Поговорите с клиентами или сотрудниками, которым предстоит пользоваться продуктом. Их ответы помогут выбрать функции первой версии и убрать неподтверждённые предположения.
3. Заранее определите измеримый результат: долю оформленных заказов, повторные обращения или время выполнения рабочего задания. Число установок рассматривают вместе с дальнейшими действиями. Для бизнеса приложение приносит пользу, когда люди выполняют нужную операцию и возвращаются при следующей потребности.

Что войдёт в первую версию (MVP)

MVP (минимально жизнеспособный продукт) – первая версия приложения, на которой проверяют основной пользовательский сценарий и интерес аудитории. В приложении доставки клиент должен выбрать предложение, указать адрес и оформить заказ. Сотрудникам нужны инструменты, через которые они получат заказ и обработают его. Дополнительные функции оценивают после проверки этого процесса.

Чтобы собрать MVP, разделите функции на две группы:

• Обязательные – без них операция не состоится: например, без проверки доступной зоны доставки.
• Улучшающие – они делают удобнее уже работающий процесс: рекомендации, расширенная программа лояльности, дополнительная персонализация. Их приоритет определяют данные и бюджет.

Отдельно опишите правила изменения и отмены заказа. Например, до передачи курьеру клиент меняет адрес самостоятельно, а после передачи отправляет запрос оператору. От этих правил зависят экраны приложения, уведомления и действия сотрудников. В Веб Ду мы прорабатываем такие сценарии при разработке приложений для iOS и Android.

Как выбрать формат мобильного приложения

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

До выбора технологии уточните, нужны ли:

• push-уведомления;
• доступ к функциям устройства: камере, геолокации, файлам;
• работа без постоянного соединения с интернетом.

Формат	Когда рассматривать	Что проверить
Адаптивный сайт	Пользователи приходят из поиска или по ссылке	Удобство оформления заявки с телефона
Веб-приложение с установкой (PWA)	Основной сценарий доступен в браузере	Поддержку нужных функций выбранными браузерами и устройствами
Кроссплатформенное приложение	Нужны iOS и Android со сходными сценариями	Работающие интеграции и ограничения выбранной технологии
Нативные приложения	Требуются специальные возможности платформ или сложная работа с устройством	Отдельный объём разработки и тестирования для каждой платформы

Коротко о форматах:

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

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

Как проходит разработка мобильного приложения

Техническое задание

Разработку начинают с задания, которое описывает работу продукта. Для клиента доставки это выбор предложения и оформление заказа, для оператора – получение заявки и изменение статуса. В задании укажите:

• какая система передаёт цены и остатки;
• кто их обновляет;
• какие действия разрешены каждой роли.

По этим сведениям команда оценивает серверную часть и объём интеграций ещё до программирования экранов.

Для каждого действия описывают, что происходит дальше. Например, после нажатия «Оплатить»:

• приложение ожидает подтверждения платёжной системы;
• при задержке показывает статус обработки;
• при отказе предлагает повторить оплату;
• повторное нажатие не создаёт новый заказ.

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

В статье о техническом задании на разработку сайта разобраны фиксация объёма и порядок приёмки. Для приложения к этому добавляют платформы, работу с разрешениями устройства и требования к выпуску в магазинах.

Прототип и дизайн

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

В UX/UI-дизайне приложения нужно предусмотреть:

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

Размеры кнопок и контраст проверяют на реальном телефоне.

Разработка и серверная часть

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

Чтобы создать мобильное приложение для существующего сайта, проверьте наличие API – интерфейса обмена данными. Через него приложение получает каталог и передаёт заказы в систему компании. Если API нет или он не поддерживает нужные действия, его разработку включают в смету. Простое открытие сайта внутри оболочки приложения не даёт удобных мобильных сценариев.

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

Как протестировать и выпустить мобильное приложение

Тестирование

Тестирование проводят на устройствах, которыми пользуется аудитория. Проверяют:

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

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

Публикация в App Store и Google Play

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

Для iOS приложение публикуют в App Store. Для этого понадобятся:

• аккаунт разработчика Apple, оформленный на компанию;
• название, краткое и полное описание, ключевые слова для поиска в магазине;
• иконка и снимки экранов для нужных размеров iPhone, а если приложение работает на планшете, то и для iPad;
• политика конфиденциальности и точное описание собираемых данных и разрешений;
• возможность удалить учётную запись внутри приложения, если в нём можно её создать: этого требуют правила App Store;
• тестовый доступ для модераторов, если функции доступны только после входа.

Для Android основная площадка – Google Play, при необходимости приложение размещают и в других магазинах, например в RuStore. Для каждой площадки подготовьте:

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

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

Можно ли создать мобильное приложение самому: через нейросеть или без кода

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

Что нужно подготовить для нейросети

Чтобы нейросеть собрала работающее приложение, ей нужна та же проектная документация, по которой работает команда разработки. Это и есть инструкция, которую загружают в нейросеть. В ней описывают:

• Цель и основной сценарий: кто пользователь и ради какого действия он открывает приложение.
• Технологии: платформы (iOS, Android, PWA), язык и фреймворк, база данных, где будет размещён сервер.
• Роли: клиент, оператор, курьер, администратор.
• Разделы и подразделы для каждой роли.
• Функции каждой роли и возможности внутри каждой функции: что пользователь может просматривать, создавать, изменять и удалять.
• Сущности и их поля: пользователь, товар, заказ, платёж, а также связи между ними.
• Статусы и правила переходов: что происходит при оплате, отмене, ошибке или потере связи.
• Интеграции: платёжная система, CRM, учётная система, службы доставки.
• Требования к дизайну: фирменные цвета, шрифты, примеры экранов.

Например, для приложения доставки описание ролей может выглядеть так:

• Клиент: каталог, корзина, оформление заказа, история заказов, бонусы.
  • изменение адреса доступно до передачи заказа курьеру;
  • отмена после передачи только через запрос оператору.
• Оператор: список новых заказов, смена статусов, обработка запросов клиентов.
• Администратор: товары и цены, зоны доставки, пользователи, отчёты.

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

Где проходит граница

Самостоятельно создать прототип мобильного приложения можно и на конструкторе с бесплатным тарифом. До выбора сервиса проверьте:

• доступны ли нужные интеграции;
• можно ли выгрузить исходный код;
• поддерживается ли публикация в магазинах;
• сколько будут стоить размещение данных и дополнительные возможности после бесплатного периода.

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

• безопасность и хранение персональных данных;
• оплата и защита от повторных списаний;
• прохождение модерации в App Store и Google Play;
• обновления под новые версии операционных систем;
• нагрузка при росте числа пользователей.

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

Примеры мобильных приложений Веб Ду

Доставка питания. В проекте Ситифуд мы разработали веб-версию и приложения для iOS и Android. Пользователь выбирает рацион и оформляет заказ, а в личном кабинете видит свои данные и бонусы. Это пример продукта для регулярной потребности в доставке питания.

Обучение. Для школы Ensina-me создан тренажёр португальского языка для iOS и Android. Он анализирует ответы и помогает ученику разбирать ошибки. Главная задача приложения связана с регулярной учебной практикой, поэтому сценарии и интерфейс отличаются от оформления покупок.

Площадка объявлений. В проекте площадки объявлений мы разработали веб-приложение и мобильные версии, предусмотрели модерацию, общение пользователей и платные услуги. Такой продукт требует заранее спроектировать действия администрации и правила обработки контента.

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

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

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

Состав работ	Трудозатраты	Стоимость	От чего зависит объём
Подготовка проектной документации	Часы аналитика	от 20 000 ₽	Число ролей и сложность основного сценария
UX/UI-дизайн	Часы UX/UI-дизайнера	от 80 000 ₽	Экраны, состояния и результаты тестирования прототипа
Мобильная разработка	Часы мобильного разработчика	от 100 000 ₽	Платформы и работа с функциями устройства
Настройка серверной части	Часы backend-разработчика	от 10 000 ₽	Правила операций, хранение данных и администрирование
Интеграции	Часы backend-разработчика	от 20 000 ₽	Готовность API, платежи и обмен с системами компании
Тестирование и запуск	Часы тестировщика и разработчика	от 20 000 ₽	Устройства, магазины и замечания при модерации

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

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

После выпуска бюджет включает поддержку сервера, исправления и проверку совместимости с новыми версиями операционных систем. Отдельно оценивают привлечение пользователей. Если у продукта есть публичный сайт, его задачи разобраны в статье о сайте для IT-продукта и SaaS.

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

Календарь разработки составляют после проверки функций и зависимостей. В него включают:

• согласование прототипа и макетов;
• программирование;
• проверку интеграций;
• подготовку релиза и модерацию в магазинах.

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

Например, в кейсе Ситифуд срок реализации составил три месяца. Он относится к проекту, который включал веб-версию и приложения для iOS и Android. Использовать этот срок как обещание для любого приложения нельзя: календарный план составляют после оценки функций и готовности исходных систем.

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

Что передать подрядчику перед оценкой

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

1. описание пользователя и операции, ради которой он открывает приложение;
2. список функций первой версии и критерии их приёмки;
3. требуемые платформы и сведения об устройствах аудитории;
4. перечень внешних систем и имеющуюся документацию API;
5. материалы бренда и готовый контент;
6. план тестового запуска, выпуска и технического сопровождения.

Если вы уже готовили описание для нейросети по списку выше, передайте его подрядчику: это ускорит оценку.

Сроки нужно считать по всему объёму проекта, включая серверную часть и проверку магазинами. О том, как подготовка влияет на календарь работ, можно прочитать в статье о сроках создания сайта. Для приложения состав этапов и оценку определяют отдельно.

В Веб Ду можно заказать мобильное приложение для бизнеса от проектирования до выпуска. Опишите основной сценарий и системы, с которыми нужно связать продукт, и мы предложим состав первой версии и оценим работы.