Фаундери питають «чи варто робити застосунок?» і зазвичай мають на увазі «чи варто бути в App Store?» Це різні питання. Перше — про мобільний UX. Друге — про дистрибуцію. Плутанина між ними коштує або €15K на застосунок, який нікому не потрібен, або 6 місяців тертя на веб-версії, яка мала бути нативною.
Цей пост — фреймворк рішень, який я проходжу з кожним фаундером, хто питає. П'ять запитань, кожне відсікає варіанти. На кінець відповідь зазвичай очевидна.
5 запитань
1. Ваша основна фіча потребує апаратних можливостей пристрою?
Камера, акселерометр, Bluetooth, NFC, офлайн-зберігання, пуш-сповіщення з високим opt-in, фонова геолокація, біометрична авторизація.
Якщо так → натив. Web API існують для деяких із них, але вони ненадійні між браузерами, обмежені на iOS Safari, і часто вимагають запитів дозволів, що вбивають конверсію. Opt-in на пуш у PWA: ~15%. У нативі: 60–75%.
Якщо ні → вебу достатньо. Більшість B2B SaaS, дашбордів, маркетплейсів, систем бронювання та контентних платформ не потребують апаратних можливостей. Адаптивний веб-застосунок на хорошому домені швидше зібрати, дешевше підтримувати, і він доступний на кожному пристрої без встановлення.
Коли я збирав застосунок E7 Shop, відповідь була однозначно натив: жести карти місць потребували 60fps на SVG із 3,000 вузлами (браузер видавав 24fps), квиткам потрібне було зашифроване офлайн-зберігання, а пуш-нагадування давали 72% opt-in. Без цих трьох вимог PWA було б достатньо.
2. «Встановіть застосунок» — розумне прохання для ваших користувачів?
Будьте чесні. Встановлення застосунку — це зобов'язання. Користувачу потрібно:
- Знайти його в сторі (або перейти за посиланням)
- Почекати завантаження
- Надати дозволи
- Створити акаунт (або увійти)
- Розібратися в інтерфейсі
На кожному кроці — відсів. Для інструменту, який використовують щодня (банкінг, месенджери, фітнес), тертя встановлення виправдане. Для чогось, що використовують раз на місяць або рідше (запис до стоматолога, перегляд меню, подання звіту про витрати), веб-застосунок із хорошим мобільним лейаутом кращий.
Правило: Якщо користувач відкриває продукт рідше 3 разів на місяць — натив надлишковий. Закладка або іконка на домашньому екрані роблять ту саму роботу без бар'єру встановлення.
3. Який ваш таймлайн запуску?
Мобільний веб-застосунок: 6–10 тижнів для MVP з одним розробником.
Нативний застосунок (React Native, обидві платформи): 8–14 тижнів для MVP з одним розробником. Плюс 1–2 тижні на рев'ю App Store (один Apple може зайняти 8 днів включаючи цикл відхилення — я через це пройшов).
Нативний застосунок з окремими кодовими базами iOS та Android: 12–20 тижнів із двома розробниками, і тепер у вас два продукти для вічної підтримки.
Якщо потрібно запуститися за менш ніж 8 тижнів → спочатку веб. Натив можна додати пізніше, коли ви валідуєте основний продукт. Зворотний шлях — почати з нативу та додати веб пізніше — дорожчий, бо ви вже написали платформенно-специфічний код, який не переноситься.
4. Який ваш бюджет на підтримку після запуску?
Це питання, яке фаундери забувають задати.
У веб-застосунку одна кодова база, один деплой, один набір залежностей. Оновлення викочуються миттєво — без процесу рев'ю, без фрагментації версій.
У нативного застосунку:
- Цикли рев'ю App Store та Play Store (1–7 днів на оновлення)
- Фрагментація версій (користувачі на v1.2, поки ви викочуєте v1.5)
- Платформенно-специфічні баги (те, що працює на iOS, але ламається на Android, і навпаки)
- Сумісність із оновленнями ОС (кожен мажорний реліз iOS/Android може щось зламати)
- Управління сертифікатами та ключами підпису
- Інфраструктура пуш-сповіщень (FCM + APNs)
Орієнтир по бюджету: Веб-застосунок коштує €500–€1,500/міс на підтримку (хостинг, моніторинг, дрібні фікси, оновлення залежностей). Нативний застосунок — €1,000–€3,000/міс за той самий рівень підтримки — і це з React Native (одна кодова база). Дві нативні кодові бази: множте вдвічі.
Якщо ви пре-ревенью або ранній ревенью і підтримка застосунку з'їсть 20%+ місячного бюджету — починайте з вебу.
5. App Store — канал дистрибуції для вас?
Для деяких продуктів бути в App Store — це виявлення. Фітнес-застосунки, ігри, утиліти — люди шукають у сторі. «Workout timer» отримує 50K пошуків на місяць. Бути в сторі — це маркетинг.
Для більшості B2B SaaS і нішевих продуктів App Store — механізм доставки, не канал виявлення. Ніхто не шукає «logistics dispatch software» в App Store. Вас знаходять через Google, реферали або прямі продажі — а потім ви направляєте до застосунку.
Якщо стор — це виявлення → натив має сенс раніше. Ви отримуєте ASO (оптимізацію для App Store), рейтинги, відгуки та присутність там, де користувачі вже бродять.
Якщо стор — лише доставка → спочатку веб, натив потім. Зберіть продукт, отримайте трекшн, додайте натив, коли користувачі попросять або коли можливості пристрою стануть реальним вузьким місцем.
Дерево рішень (резюме)
Потрібні апаратні можливості (камера, офлайн, пуш, жести)?
├── Так → Натив
└── Ні
└── Користувачі відкривають 3+ рази/місяць?
├── Так
│ └── Таймлайн запуску > 8 тижнів?
│ ├── Так → Натив
│ └── Ні → Спочатку веб, натив потім
└── Ні → Веб-застосунок
Якщо дерево привело до «Натив» — наступне питання React Native чи Flutter — я розібрав це окремо.
Гібридний шлях, що підходить більшості фаундерів
Для більшості стартапів, із якими я працюю, відповідь: спочатку веб, натив коли заслужить.
- Тижні 1–10: Зібрати адаптивний мобільний веб-застосунок. Запустити. Отримати користувачів. Валідувати, що людям реально потрібен продукт.
- Місяці 3–6: Дивитися дані використання. Якщо мобільні користувачі — 60%+ трафіку і ви бачите запити фіч, що потребують API пристрою — планувати натив.
- Місяці 6–12: Зібрати натив на React Native зі спільним бекендом. API вже побудований, модель даних перевірена, і ви точно знаєте, які фічі важливі.
Цей шлях коштує менше на старті, дозволяє валідувати перед комітом у натив і уникає підтримки застосунку, який ніхто не завантажує.
Зворотний шлях — збирати натив першим — має сенс лише коли апаратні можливості пристрою необхідні з першого дня. E7 Shop був одним із таких випадків. Більшість продуктів — ні.
Скільки коштує
Реальні цифри з моїх проєктів:
| Шлях | Таймлайн | Діапазон вартості |
|---|---|---|
| Мобільний веб-застосунок (MVP) | 6–10 тижнів | €6K–€12K |
| React Native застосунок (MVP, обидві платформи) | 8–14 тижнів | €8K–€18K |
| Веб → додати натив потім | 6–10 тижнів + 8–12 тижнів | €14K–€25K загалом |
| Окремі iOS + Android | 12–20 тижнів | €20K–€40K |
Шлях «спочатку веб, натив потім» виглядає дорожчим у сумі — але розтягнутий на 6–12 місяців, він менш ризикований. Ви витрачаєте бюджет на натив після валідації, а не до.
Ось як виглядає повний розклад вартості MVP, якщо хочете побачити, куди йдуть години.
Не впевнені, який шлях підходить вашому продукту? Запишіться на скоупінг-дзвінок — я скажу, що б зібрав і чому, виходячи з ваших користувачів, таймлайну та бюджету. Без зобов'язань, лише ясність.