Сайт или мобильное приложение: что выбрать

Три формата, а не два

Обычно спорят о двух вариантах, но форматов три, и у каждого своя задача.

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

Цены — наши ориентиры на октябрь 2026 года. Точная оценка зависит от сценариев, интеграций и дизайна.

Когда достаточно сайта

Сайт открывается по ссылке, индексируется поиском и не требует установки. Для большинства компаний, которые продают услуги, этого достаточно.

Сайт разумнее, если:

• человек решает задачу редко — записывается к врачу, выбирает подрядчика, бронирует зал;
• основные клиенты приходят из поиска и рекламы;
• продукт ещё ищет позиционирование и его нужно быстро менять;
• важны скорость запуска и простое обновление контента;
• камера, геолокация и фоновая работа не нужны.

Для стоматологии Солид Дент мы сделали новый сайт, а не приложение: отдельные страницы под 11 направлений и 11 врачей, цены прямо в меню, запись в один клик и мессенджеры в один тап. Пациент приходит не каждый день — ему важно быстро найти клинику, понять цену и записаться, и сайт делает это лучше любого приложения.

Когда нужен веб-сервис

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

Веб-сервис подходит, когда:

• у продукта несколько ролей, например покупатели и продавцы, клиенты и исполнители;
• пользователи работают за компьютером или с длинными формами и таблицами;
• нужно быстро проверить экономику и сценарии до вложений в приложения;
• продукт — внутренний инструмент компании.

Для многих продуктов веб-версия становится первым полноценным MVP: она проверяет сценарии, роли и экономику, а потом становится понятно, какие функции действительно стоит переносить в приложение.

PWA: веб-приложение на главном экране

Прогрессивное веб-приложение (PWA) — это веб-сервис, который можно установить на главный экран телефона. Оно открывается без адресной строки, частично работает без сети и может присылать уведомления — на iPhone это стало возможно с iOS 16.4 для приложений, добавленных на экран.

PWA хорошо подходит для MVP и внутренних инструментов. Но у неё меньше доступа к функциям телефона, её нет в магазинах приложений, и пользователи реже понимают, как её «установить».

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

Приложение имеет смысл, когда формат использования повторяется часто и телефон влияет на продукт.

Типичные основания:

• продуктом пользуются каждый день или несколько раз в неделю;
• важны push-уведомления, которые возвращают человека;
• нужны камера, Bluetooth, геолокация, NFC или биометрия;
• часть сценариев должна работать без стабильного интернета;
• приложение становится основным рабочим инструментом — для курьера, мастера, менеджера на выезде.

Само присутствие в App Store или Google Play спрос не создаёт. Заранее продумайте, откуда придут установки и почему человек оставит приложение на телефоне, а не удалит после первого запуска.

Учитывайте и расходы после релиза: поддержка новых версий iOS и Android, проверка обновлений в магазинах, исправления, поддержка пользователей и аналитика. Приложение — это постоянный продукт, а не разовый проект.

Нативно или кроссплатформенно

Нативная разработка — это отдельные приложения на Swift для iOS и на Kotlin для Android. Она даёт максимальную производительность и полный доступ к устройству, но стоит дороже: фактически вы делаете два продукта.

Кроссплатформенные технологии — Flutter, React Native, Kotlin Multiplatform — позволяют писать одну кодовую базу для обеих платформ. Для большинства бизнес-приложений этого достаточно: каталоги, записи, маркетплейсы, кабинеты. Нативный путь стоит выбирать, когда важны сложная графика, обработка видео, работа с внешними устройствами или максимальная скорость.

Как выбрать формат: оценка сценариев

Главная ошибка — выбирать формат для продукта целиком. Правильнее выбрать его для каждого сценария: что-то удобнее в браузере, что-то — в телефоне.

Вот как может выглядеть такая оценка для сервиса, где заведения приглашают блогеров в гости в обмен на контент:

Такой продукт мы сделали для goesti: сайт, веб-кабинеты для бизнеса и блогеров и нативные приложения для iOS и Android с общей дизайн-системой. Меньше чем за полгода сервис вырос до 26 000 пользователей и работает в 100+ городах 17 стран.

Чтобы оценить свой продукт, пройдите по шагам:

1. Выпишите роли пользователей и 5–10 главных сценариев для каждой.
2. Для каждого сценария отметьте, как часто он повторяется.
3. Отметьте, нужны ли ему функции телефона и можно ли выполнить его в браузере.
4. Посмотрите, откуда придут люди для этого сценария: из поиска, рекламы, по приглашению.
5. Оцените, сколько платформ команда сможет поддерживать после запуска.

Если большая часть ценности доступна в браузере, начинайте с сайта или веб-сервиса. Если ключевые сценарии требуют телефона, проектируйте приложение, но не забывайте о сайте — для презентации, поддержки и поискового трафика.

Особенности России в 2026 году

Рынок приложений в России заметно отличается от мирового, и это стоит учесть до старта разработки.

• RuStore. Магазин предустановлен на смартфоны, которые продаются в России, а публикация в нём бесплатна. Для Android-аудитории это обязательная площадка наряду с Google Play.
• Монетизация. App Store и Google Play доступны, но возможности приёма платежей и выплат для российских компаний ограничены, а правила меняются. Если продукт продаёт подписки, заранее решите, где человек будет платить: на сайте, через RuStore или в приложении — и сверьтесь с актуальными правилами каждого магазина.
• Привлечение установок. Реклама в App Store для российской аудитории недоступна с 2022 года, поэтому установки приводят через сайт, рекламу во ВКонтакте и Яндексе, блогеров и оптимизацию страниц в магазинах.
• Персональные данные. Данные российских пользователей сначала записываются в базу на территории России — так требует 152-ФЗ. Это влияет на выбор серверов и сторонних сервисов: аналитики, рассылок, хранилищ.

От идеи к приложению: порядок работы

1. Исследование: роли, сценарии, конкуренты и то, как люди решают задачу сейчас.
2. Прототип ключевого пути и проверка на 5–7 будущих пользователях.
3. MVP в вебе или сразу в приложении — по таблице сценариев.
4. Аналитика с первого дня: события, воронки, удержание.
5. Приложение для самого частого сценария, когда видно, что люди возвращаются.
6. Развитие по данным, а не по списку пожеланий.

Что заложить в бюджет кроме разработки

Стоимость разработки — только часть расходов. Чтобы продукт не остановился после релиза, сразу заложите:

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

Один продукт, а не набор экранов

Сайт, веб-кабинет и приложение должны опираться на единую модель продукта: одинаковые сущности, статусы, правила и визуальные принципы. Тогда пользователь не путается, переходя с сайта в приложение, а команда не тратит время на согласование трёх разных логик.

На старте полезно подготовить:

• карту ролей и сценариев;
• прототип ключевого пути;
• состав MVP;
• общую дизайн-систему;
• требования к аналитике;
• план развития после первого релиза.

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