За последнее время нам не раз задавали один и тот же вопрос: зачем покупать сайт, если можно сразу выпустить мобильное приложение? Вопрос логичный. Телефон всегда под рукой, а иконка на экране выглядит как готовый продукт. Но здесь легко перепутать удобный интерфейс с самим бизнесом. Мобильное приложение без сайта не даёт ни гарантированного трафика, ни независимости, ни запасного входа для клиентов.
Мы сами на время добавили тариф «Только мобильное приложение» — клиенты спрашивали, на рынке появлялись похожие предложения, и спрос был понятен. А потом начали разбирать такой запуск так, как разбираем реальные проекты: где будут храниться данные, откуда придут первые пользователи, кому принадлежат аккаунты и что произойдёт после отказа магазина. Ответ оказался неудобным, зато честным: отдельное приложение слишком часто продают как готовый бизнес, хотя почти все риски остаются у покупателя.
Главная мысль
Приложение — отличный дополнительный канал, но плохая единственная точка входа. Собственный домен, веб-платформа и общая база сохраняют бизнес, даже если магазин ограничит или удалит приложение.
Почему мы убираем тариф «Только мобильное приложение»
Собрать APK-файл и показать клиенту карточку в магазине — самая короткая часть пути. Настоящая работа начинается дальше: сервер, база данных, юридические документы, привлечение аудитории, аналитика, обновления и поддержка. И ещё один вопрос, который почему-то часто оставляют на потом: куда пойдёт пользователь, если приложение завтра станет недоступно?
От мобильной разработки мы не отказываемся — наоборот, приложение Adwos остаётся важной частью продукта. Меняется другое: мы больше не хотим предлагать его отдельно от полноценной веб-системы. Когда сайт и приложение работают с одной базой, владелец получает несколько точек доступа к бизнесу, а не одну красивую оболочку.
Продать отдельное приложение проще. Но наша работа заканчивается не в момент оплаты — она имеет смысл только тогда, когда у клиента действительно запускается проект.
— Позиция Adwos
Что скрывается за формулировкой «приложение без сайта»
Чтобы не рассуждать абстрактно, возьмём открытое предложение UniSite, которое продвигается как запуск маркетплейса без сайта. На момент проверки, 22 августа 2026 года, APP START стоил 60 000 ₽ и продавался без исходного кода. На карточке всё выглядит просто. Но публикация оплачивается отдельно: 7 490 ₽ за Google Play и 10 490 ₽ за App Store. Стартовая сумма сразу вырастает до 77 980 ₽ — и это ещё без сервера, домена, аккаунтов разработчиков, рекламы и будущих обновлений.
Если CMS раньше не покупалась, предлагается APP + ADMIN за 69 900 ₽. Вместе с публикацией в двух магазинах получается 87 880 ₽. Исходный код — уже 250 000 ₽, одно обновление — ещё 10 500 ₽. И вот здесь возникает главная подмена понятий: приложению всё равно нужны сервер, CMS, API и веб-панель. «Без сайта» в такой схеме означает лишь отсутствие публичного веб-каталога. Веб-инфраструктура и расходы никуда не исчезают.
| Маркетинговый тезис | Фактическое условие | Риск для покупателя |
|---|---|---|
| «Приложение за 60 000 ₽» | Публикация оплачивается отдельно; минимум — 77 980 ₽ | Цена карточки не равна стоимости запуска |
| «Маркетплейс без сайта» | Необходимы сервер, CMS, API и веб-панель | Веб-инфраструктура никуда не исчезает |
| «Без домена и хостинга» | Нужны сервер и публичные страницы поддержки, документов и удаления аккаунта | Остаются регулярные расходы и юридические обязанности |
| «Приложение даёт больше трафика» | Нет гарантии установок без рекламы, ASO и наполненного каталога | Опубликованное приложение может остаться пустым |
| «Полный контроль» | Исходный код не входит в базовый тариф | Возникает зависимость от поставщика и стоимости обновлений |
| «Готовый бизнес» | Продаётся программный продукт, а результат зависит от запуска и продвижения | Риск окупаемости полностью остаётся у клиента |
Важная оговорка: это не доказывает, что приложение плохое. Вопрос вообще не в качестве кода. Вопрос в том, что крупная цифра на карточке тарифа и реальная стоимость запуска — разные вещи. Покупателю стоит считать не цену иконки в магазине, а стоимость всей системы хотя бы на первый год работы.
Мобильное приложение не создаёт трафик автоматически
Самая опасная иллюзия в подобных предложениях звучит так: люди сидят в приложениях, значит новое приложение само получит аудиторию. Нет. Люди проводят время в сервисах, которые уже знают: в мессенджерах, банках, социальных сетях и крупных маркетплейсах. Неизвестное приложение сначала нужно найти, затем установить, открыть, пройти регистрацию — и только после этого убедить человека что-то сделать.
- платная реклама и продвижение в социальных сетях;
- ASO-оптимизация карточек в магазинах приложений;
- контент, публикации, партнёрства и PR;
- реферальная программа и работа с действующей аудиторией;
- бюджет на привлечение продавцов и покупателей;
- аналитика стоимости установки, регистрации и целевого действия.
У маркетплейса двойная проблема холодного старта
У маркетплейса задача ещё сложнее. Нужно привести продавцов, наполнить каталог и почти одновременно найти покупателей. Если внутри пусто, публикация в App Store ситуацию не спасёт. Магазин приложений даёт способ установки, но не решает проблему холодного старта и не создаёт бизнес-модель за владельца.
Сайт снимает хотя бы один барьер: объявление, товар или услугу можно открыть обычной ссылкой — без установки и регистрации. Эту ссылку можно отправить в Telegram, разместить в соцсетях или вывести в поиске. Google прямо объясняет, что поиск работает с содержимым веб-страниц. Deep links полезны, когда приложение уже установлено, но заменить индексируемый сайт они не могут.
Если совсем коротко: приложение помогает вернуть уже знакомого клиента. Сайт помогает этому клиенту впервые вас найти.
App Store и Google Play вам не принадлежат
Есть ещё одна неприятная, но важная вещь: магазин приложений — чужая площадка. Публикация не даёт пожизненного права оставаться в каталоге. Apple может удалить продукт, если он перестал работать, устарел или больше не соответствует требованиям. Компания прямо пишет об этом в программе App Store Improvements.
У Google свои проверки, удаления и приостановки. Кроме того, приложение приходится регулярно подтягивать под новые версии Android API. Если этого не делать, оно может перестать показываться новым пользователям на современных устройствах. Это не страшилка разработчиков, а опубликованное требование Google Play.
- изменение правил модерации и требований к контенту;
- новые требования к персональным данным и удалению аккаунтов;
- ограничение способов оплаты и монетизации;
- блокировка аккаунта разработчика;
- региональные и санкционные ограничения;
- необходимость обновлять SDK, зависимости и ключи подписи.
Для российского бизнеса к обычным техническим рискам добавляются санкционные. Они уже работают на практике: Google приостановил монетизацию для разработчиков, которые получают выплаты на банковские счета в России. Текущий статус компания публикует в справке Play Console.
Гарантировать вечное присутствие в магазинах невозможно
Разработчик может качественно поддерживать продукт, но он не принимает решения за Apple и Google. Поэтому обещание «приложение никогда не удалят» нельзя считать реальной гарантией.
Почему в любом случае нужен собственный сайт
Именно здесь формула «сайт вообще не нужен» начинает рассыпаться. Даже если вся основная работа идёт в приложении, бизнесу нужен хотя бы одностраничный сайт на собственном домене и открытые юридические страницы. Это официальное место, где пользователь может проверить владельца сервиса, связаться с поддержкой, узнать о сбое и прочитать правила обработки данных.
Это не наша перестраховка. Apple просит Privacy Policy URL и Support URL с рабочими контактами. Google Play требует общедоступную политику конфиденциальности, а если в приложении есть регистрация — ещё и веб-страницу, через которую человек сможет запросить удаление аккаунта. Всё это закреплено в документации App Store Connect и правилах Google Play.
Есть и российское законодательство. Если сервис собирает персональные данные через интернет, оператор обязан обеспечить свободный доступ к политике их обработки. Требование содержится в статье 18.1 Федерального закона № 152-ФЗ.
- политика обработки персональных данных;
- пользовательское соглашение;
- публичная оферта или правила оказания услуг;
- согласие на обработку персональных данных;
- правила размещения пользовательского контента;
- порядок удаления аккаунта и персональных данных;
- сведения о юридическом лице или ИП и контакты поддержки.
У интернет-магазина, доски объявлений и сервиса услуг набор документов будет отличаться. На него влияют платежи, типы данных и страны работы. Поэтому список выше — ориентир, а не готовый юридический комплект: финальные документы лучше проверить с профильным юристом.
Каким должен быть минимальный одностраничный сайт
- название, назначение и основные возможности платформы;
- информация о текущей работоспособности сервиса;
- официальные ссылки на версии приложения;
- контакты технической поддержки;
- сведения о владельце, реквизиты и юридическая информация;
- ссылки на политику конфиденциальности, соглашение и удаление аккаунта;
- инструкции для клиентов на случай недоступности приложения.
Лендинг — необходимый минимум, но не полноценный резерв
Лендинг закрывает вопросы доверия, документов и связи. Но если вы хотите сохранить сам сервис после удаления приложения, понадобится адаптивная веб-версия с авторизацией и основными функциями.
| Компонент | Его задача |
|---|---|
| Одностраничный сайт | Описание сервиса, документы, контакты, статус и официальные ссылки |
| Веб-платформа | Поиск, SEO, регистрация и работа через браузер без установки |
| Общая серверная часть | Единая клиентская база, объявления, сделки, интеграции и резервные копии |
| Мобильное приложение | Удобство постоянных пользователей, push-уведомления и функции смартфона |
Главное — сохранить не приложение, а бизнес и клиентскую базу
Владелец бизнеса зарабатывает не на самой сборке приложения. Его настоящий актив — клиенты, данные, каталог, домен и рабочие процессы. Поэтому удаление из магазина может быть неприятной проблемой, но не должно превращаться в потерю всего проекта. Для этого сайт и приложение обязаны работать с одной системой аккаунтов и подконтрольной владельцу базой.
- домен и основные учётные записи принадлежат владельцу бизнеса;
- сайт и приложение используют общую клиентскую базу;
- пользователь может войти через браузер с прежними данными;
- контакты, объявления и история операций не зависят от магазина;
- создаются регулярные резервные копии и предусмотрен экспорт данных;
- аккаунты разработчиков оформлены на заказчика;
- оговорена передача исходного кода, ключей подписи и инструкций по сборке.
При такой схеме приложение наконец занимает правильное место — становится удобным каналом, а не единственной опорой. Если его временно удалят, клиент откроет сайт и войдёт в тот же аккаунт. Бизнес сохранит данные, аудиторию и возможность говорить с пользователями напрямую.
Что входит в реальную стоимость приложения для бизнеса
- лицензия или разработка приложения;
- публикация и аккаунты разработчиков;
- сервер, база данных, API, домен и SSL;
- веб-панель управления и публичные юридические страницы;
- обновления под новые версии iOS и Android;
- поддержка, мониторинг, резервное копирование и восстановление;
- реклама, ASO, контент, аналитика и привлечение двух сторон маркетплейса.
Мы советуем сделать простое упражнение: попросить у продавца не цену запуска, а смету первого года. Отдельно зафиксировать стоимость обновлений, владельца инфраструктуры, условия экспорта и план действий на случай отказа магазина. После такого расчёта многие «дешёвые» предложения начинают выглядеть совсем иначе.
Почему решение Adwos выгоднее клиенту в долгосрочной перспективе
Честно говоря, оставить отдельный тариф было бы проще. На него есть спрос, его легко показать в рекламе, а короткое предложение всегда продаётся лучше сложного объяснения. Но после разговоров с клиентами мы увидели одну и ту же ошибку: человек думает, что за фиксированную сумму покупает готовый маркетплейс, которому не нужен сайт и который сам получит мобильный трафик. Мы не хотим зарабатывать на этом ожидании.
Поэтому для новых заказов тариф «Только мобильное приложение» будет отключён. Наша рекомендация — веб-платформа Adwos, общая база, юридические страницы, мобильные приложения и понятный план продвижения. Да, это сложнее, чем купить одну сборку. Зато в результате у владельца остаётся работающий цифровой актив, а не зависимость от одной кнопки в чужом магазине.
Нам важнее, чтобы система работала после продажи, чем чтобы предложение красиво выглядело до оплаты.
— Adwos CMS
Что спросить перед покупкой отдельного мобильного приложения
- На чьё имя будут оформлены аккаунты App Store и Google Play?
- Входит ли публикация в первоначальную стоимость?
- Получаете ли вы исходный код, инструкции по сборке и ключи подписи?
- Сколько стоят обязательные обновления приложения?
- Где размещаются сервер, база данных и резервные копии?
- Можно ли экспортировать пользователей, объявления и историю операций?
- Как клиенты будут пользоваться сервисом, если приложение удалят?
- Кто готовит юридические документы и страницу удаления аккаунта?
- За счёт чего появятся первые продавцы, объявления и покупатели?
Если продавец уверенно говорит про дизайн, push-уведомления и публикацию, но начинает путаться на вопросах о данных, аккаунтах и резервном доступе, перед вами программный продукт — не готовый бизнес. О выборе технической основы мы отдельно рассказали в материале о том, как выбрать CMS для доски объявлений и маркетплейса.
Частые вопросы о приложении без сайта
Можно ли технически запустить мобильное приложение без публичного сайта?
Да, публичный каталог в браузере можно не делать. Но сервер, база данных, API, административная панель, домен и страницы с документами всё равно понадобятся. Точнее называть такую схему не «без сайта», а «без полноценной публичной веб-версии».
Достаточно ли одностраничного сайта?
Для презентации сервиса, контактов и документов — да. Это разумный минимум. Но лендинг не позволит разместить объявление или войти в личный кабинет, поэтому для полноценного резервного доступа нужна адаптивная веб-версия с общей базой.
Что произойдёт, если приложение удалят из App Store или Google Play?
Как минимум прекратятся новые установки из этого магазина. Могут возникнуть проблемы с обновлением и повторной установкой. Если есть общая веб-платформа, пользователь просто откроет браузер и войдёт с прежними данными.
Приносит ли публикация приложения органический трафик?
Иногда приложение получает немного поисковых показов внутри магазина, но публикация сама по себе не гарантирует ни установок, ни регистраций, ни сделок. Понадобятся ASO, реклама, контент и аналитика. А маркетплейсу придётся отдельно привлекать обе стороны — продавцов и покупателей.
Когда отдельное мобильное приложение действительно оправдано?
Когда уже есть серверная часть, собственный домен, клиентская база, понятный способ привлечения пользователей и резервный веб-доступ. Тогда приложение действительно решает задачи удобства и удержания, а не изображает из себя всю платформу сразу.
Вывод: приложение должно дополнять платформу, а не заменять её
Мы за мобильные приложения. Но не за ситуацию, в которой весь бизнес держится на решении модератора App Store или Google Play. Никто не может обещать вечное присутствие в магазинах. Зато можно заранее сделать так, чтобы удаление приложения не забрало вместе с ним клиентов, данные и возможность продолжать работу.
Мы считаем здравой такую последовательность: собственный домен → веб-платформа → единая клиентская база → юридические документы → мобильные приложения → системное продвижение. Сначала фундамент, затем дополнительный удобный канал — не наоборот.
Если вы сейчас выбираете между отдельным приложением и полноценной платформой, напишите команде Adwos. До покупки разберём, кому будут принадлежать данные и аккаунты, сколько точек доступа получат клиенты и во что обойдётся не первый день, а нормальная работа проекта.
Цены и условия упомянутого предложения проверены 22 августа 2026 года и со временем могут измениться. Ссылки на сайт конкурента мы намеренно не приводим. Материал отражает позицию Adwos и не является юридической консультацией.
