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

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

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

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

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

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

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

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

Приложение из App Store и Google Play

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PWA как промежуточный вариант

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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