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

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

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