Мобільний додаток чи веб-сервіс

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

Додаток з 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 щороку випускають нові версії систем, змінюють вимоги до додатків і правила публікації. Збірку доводиться оновлювати, навіть якщо у вашому бізнесі нічого не змінилося.

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

PWA як проміжний варіант

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

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

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

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

Як перевірити ідею до великого бюджету

Найдорожча помилка це замовити повну систему під припущення. Власник описує два десятки екранів, платить за всі, а після запуску з’ясовується, що люди користуються трьома. Тому першою ми робимо коротку робочу версію з одним головним сценарієм. У нас це MVP від $4 000 і від 1,5 місяця, склад робіт описаний у розділі розробки веб-додатків.

З чого складається перша версія

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

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

Помилки, які дорого коштують

Ці ситуації ми бачимо регулярно, коли до нас приходять з готовим продуктом на доопрацювання.

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

Висновки

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

• Нечасті візити, трафік з реклами, потреба працювати ще й з комп’ютера: беріть веб-сервіс.
• Щоденне використання зі складними фоновими сценаріями й глибокою інтеграцією з телефоном: закладайте мобільну розробку разом із серверною частиною.
• Потрібна іконка на екрані без важких мобільних функцій: подивіться на PWA. Такий варіант дорожчий за звичайний веб-додаток, але дешевший за дві нативні збірки.
• Ідея поки не підтверджена попитом: починайте з короткої робочої версії і додавайте функціонал за реальними даними.

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