Мобильное приложение или веб-сервис

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

Приложение в App Store и Google Play окупается в другой ситуации. Когда клиент или сотрудник заходит в продукт каждый день, а сценарий требует стабильной фоновой работы, полного доступа к возможностям телефона и предсказуемого поведения без сети. Без таких сценариев иконка на экране телефона так и останется иконкой. Ниже разбираем, как определить свой случай, в какие деньги и сроки это выходит и где владельцы ошибаются чаще всего.

Что вы получаете в каждом случае

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

Веб-сервис в браузере телефона

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

Такой формат хорошо ложится на задачи, где человек заходит с разных устройств: утром с телефона, днем с ноутбука в офисе. Веб-сервис одинаково откроется на Android, iPhone и Windows, и платить за отдельную сборку под каждую систему не придется.

Приложение из магазина

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

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

Когда достаточно веб-сервиса

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

• Клиент заходит редко. Запись к мастеру, заказ доставки раз в неделю, оплата счета, проверка статуса заявки. Ради такого никто не пойдет в магазин приложений и не станет тратить память телефона.
• Трафик приходит из рекламы и поиска. Ссылка открывается сразу. Установка приложения добавляет лишний шаг, на котором часть людей отсеивается.
• Продукт нужен и на компьютере. Менеджеры, бухгалтерия, склад работают на больших экранах, и кабинет в браузере им удобнее любой мобильной версии.
• Набор функций пока меняется. Пока вы ищете рабочую модель, правки выходят каждую неделю. В вебе это обычный релиз, в магазинах каждая версия ждет модерации.
• Аудитория широкая и разная. У части клиентов старые телефоны с небольшим объемом памяти, и устанавливать они ничего не станут.

По нашему опыту, заметная доля запросов на приложение после такой проверки превращается в кабинет в браузере. Заказчик получает ту же пользу быстрее и за меньшую сумму, а оставшийся бюджет вкладывает в рекламу и контент.

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

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

• Ежедневный возврат пользователя. Служба такси, доставка еды, фитнес, финансовый продукт, программа лояльности с баллами. Человек открывает сервис постоянно, и поиск нужной вкладки в браузере его утомляет.
• Пуш-уведомления как часть услуги. Статус заказа, изменение графика, напоминание о визите. На iPhone возможности веб-пушей скромнее, и приложение здесь выигрывает.
• Работа без стабильного интернета. Выездные бригады, торговые представители, склад в подвальном помещении, курьер в лифте. Данные сохраняются на устройстве и уходят на сервер, когда появится сеть.
• Оборудование телефона. Сканер штрихкодов на складе, фото дефекта с привязкой к заявке, маршрут водителя, подпись клиента пальцем на экране.
• Инструмент для собственных сотрудников. Когда устройства корпоративные, приложение ставится централизованно, и магазин приложений вообще не участвует.

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

Деньги и сроки

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

Состав работ по каждому уровню и примеры проектов собраны на странице разработки веб-приложений.

Работы поменьше считаем иначе. Точечная доработка готового проекта выходит от $300 до $1 000, отдельные модули и интеграции через API от $500 до $2 000, почасовой формат стоит от $20 за час. Условия и примеры собраны на странице кастомной разработки.

Что приложение добавляет сверх этого бюджета

• Две сборки вместо одной. iOS и Android построены на разных технологиях. Даже при кроссплатформенном подходе остается отдельное тестирование, отдельные сложности и отдельные правки под каждую систему.
• Серверная часть нужна в любом случае. Приложение без бэкенда это витрина. Данные, роли, оплаты, отчеты живут на сервере, и эту работу вы оплачиваете в обоих сценариях одинаково.
• Аккаунты и публикация. Ежегодный взнос за аккаунт разработчика Apple, платеж за аккаунт Google, подготовка страницы в магазине со скриншотами и описанием.
• Модерация каждого релиза. Проверка может вернуть сборку с замечанием, и запуск сдвигается на несколько дней. Планировать рекламную кампанию день в день с релизом рискованно.
• Постоянное сопровождение. Apple и Google каждый год выпускают новые версии систем, меняют требования к приложениям и правила публикации. Сборку приходится обновлять, даже если в вашем бизнесе ничего не поменялось.

Из-за этого одинаковый набор функций в приложении обходится заметно дороже в разработке и еще дороже во владении. Технический абонемент на веб-сервис у нас начинается от $400 в месяц, формат с 40 часами работы ежемесячно от $800. Мобильная сборка требует своего времени на каждую платформу поверх этой суммы.

Промежуточный вариант: PWA

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

Кому подходит PWA

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

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

Как проверить идею до большого бюджета

Самая дорогая ошибка это заказать полную систему под предположение. Владелец описывает два десятка экранов, платит за все, а после запуска выясняется, что люди пользуются тремя. Поэтому первой мы делаем короткую рабочую версию с одним главным сценарием. У нас это MVP от $4 000 и от 1,5 месяца, состав работ описан в разделе разработки веб-приложений.

Из чего состоит первая версия

• Один главный сценарий до конца. Тот путь, ради которого клиент пришел: оформить заказ, оставить заявку, увидеть свой баланс. Остальные разделы ждут следующего этапа.
• Вход и роли. Клиент, менеджер, администратор видят разные данные. Разделение прав закладывается сразу, переделывать его потом дорого.
• Админка для вашей команды. Чтобы менять цены, тексты и статусы без обращения к разработчику.
• Оплата, если это источник денег. Подключение платежного сервиса к первому релизу дает понятную картину по заказам.
• Аналитика событий. Нужно видеть, на каком экране люди останавливаются. Без этого следующий этап делается вслепую.

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

Ошибки, которые дорого обходятся

Эти ситуации мы видим регулярно, когда к нам приходят с готовым продуктом на доработку.

• Приложение под разовое действие. Никто не устанавливает программу, чтобы один раз оставить заявку или посмотреть прайс. Для таких задач достаточно страницы с формой.
• Расчет без стоимости владения. В смете есть разработка, и нет поддержки, серверов, обновлений под новые версии систем. Через год продукт останавливается, потому что на него не заложили бюджет.
• Перенос всего сайта в приложение. Каталог, блог, страница контактов в мобильной сборке никому не нужны. Туда идет только то, чем пользуются постоянно.
• Коробочное решение там, где нужна своя логика. Готовые платформы экономят время на старте и упираются в потолок при нестандартных процессах. Разницу мы разбирали в материале про готовое решение или кастомную разработку.
• Запуск без плана на первые недели. Продукт отдали, и дальше тишина: никто не смотрит ошибки, не собирает отзывы, не правит проблемные экраны. Об этом у нас есть отдельный материал про первые 90 дней после запуска.

Выводы

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

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

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