Фаундеры спрашивают «стоит ли делать приложение?» и обычно имеют в виду «стоит ли быть в 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, если хотите увидеть, куда уходят часы.
Не уверены, какой путь подходит вашему продукту? Запишитесь на скоупинг-звонок — я скажу, что бы собрал и почему, исходя из ваших пользователей, таймлайна и бюджета. Без обязательств, только ясность.