Приложение и сайт: разделение функций и общие данные

Клиент оформляет заказ в приложении, а потом звонит и просит «посмотреть в личном кабинете на сайте» — и не находит там ничего. Или наоборот: на сайте висит старая цена, потому что менеджер обновил прайс только в админке приложения. Причина одна — функциональность поделили задним числом, а не на этапе проектирования.

Сайт разработки приложений и мобильных клиентов должен начинаться с одного вопроса: какое действие где живёт. Ответ на него определяет архитектуру и бюджет: по нашей практике, спор о функциях на старте дешевле переделки на 400–900 тыс. ₽. Ниже — рабочая схема разделения функций, общий бэкенд на два клиента, честная стоимость обоих контуров на 2026 год и грабли, из-за которых проекты дублируют данные и ломают аналитику.

Ключевые выводы

• Один бэкенд на сайт и приложение дешевле двух раздельных систем на 30–45% за три года владения.
• Быстрый вход, push-уведомления, камера, офлайн и биометрия — зона приложения. Каталог, SEO-страницы, оплата с десктопа и длинные формы — зона сайта.
• Разработка интернет приложений (веб-клиент) стоит 1,2–3 млн ₽, мобильный клиент к тому же API — 1,8–3,5 млн ₽.
• Общий API и единая база экономят 400–900 тыс. ₽ в год на поддержке двух версий логики.
• Дублирование логики на клиентах — причина 60–70% расхождений в данных между сайтом и приложением.
• ИИ для разработки ускоряет рутину на 20–35%, но архитектурные решения по-прежнему принимает человек.

Правило разделения: где живёт каждая функция

Функция живёт там, где ей пользуются в момент необходимости. Если действие совершается «на ходу» и требует камеры, геолокации или уведомления — это приложение. Если человек сидит за компьютером и сравнивает, читает, заполняет — это сайт.

Простой тест из трёх вопросов к каждой функции:

1. Нужен ли доступ к железу телефона — камера, сканер, GPS, биометрия, push? Да — приложение.
2. Требуется ли офлайн или работа в момент, когда интернет нестабилен? Да — приложение.
3. Функция приносит трафик из поиска или используется для длинного сравнения и оплаты с ноутбука? Да — сайт.

Если ответы «нет» на все три, функция, скорее всего, должна быть общей и обслуживаться одним API.

Что нельзя разделять

Пять вещей обязаны быть общими, иначе вы получите два продукта вместо одного:

• Пользователь и аутентификация. Один аккаунт, один профиль, один механизм сброса пароля.
• Каталог, цены и остатки. Один источник правды; расхождение цен между сайтом и приложением — прямой путь к жалобам и возвратам.
• Корзина и заказы. Клиент начал на сайте, закончил в приложении — это должно работать.
• Платежи и чеки. Один шлюз, одна история транзакций, один интеграционный контур с 1С или CRM.
• Аналитика. Сквозная идентификация пользователя: иначе вы не соберёте путь клиента и не посчитаете окупаемость.

Архитектура: один API на два клиента

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

Рабочая схема выглядит так: PostgreSQL как основная база, отдельный слой API, кеш (Redis) для каталога, объектное хранилище для файлов, интеграции с 1С, CRM и платёжными провайдерами — на серверной стороне. Веб-клиент на React или Next.js, мобильные клиенты на Flutter или React Native либо нативные. Выбор между подходами разобран в материале Flutter или React Native.

Системы разработки приложений и сайтов в такой схеме сводятся к одному контуру: библиотека компонентов, дизайн-токены и API-клиент переиспользуются между клиентами. Что экономят:

1. Одна реализация бизнес-логики вместо трёх — минус 400–900 тыс. ₽ в год на поддержке.
2. Один тестовый контур и один набор автотестов API — минус 25–35% времени на регресс.
3. Единая аналитика и единая база клиентов — можно считать LTV без склейки отчётов.

Сколько стоит: сайт, приложение, вместе

Цифры ниже — под ключ, с дизайном, разработкой, тестированием и запуском. Диапазон зависит от числа экранов, интеграций и требований к нагрузке.

Порядок запуска, который экономит деньги: сначала API, затем сайт, затем приложение. Сайт быстрее приносит трафик и заявки, а приложение выходит на подготовленную серверную часть без переделок. Обратный порядок «сначала приложение, потом сайт» обычно приводит к тому, что API приходится переписывать под веб-сценарии — это плюс 300–600 тыс. ₽.

Процессы разработки приложений и сайта в одной команде

Если сайт делает одна студия, а приложение — другая, вы становитесь переводчиком между ними. Обычно это заканчивается двумя базами, дублирующимися справочниками и ручной синхронизацией заказов. Процессы разработки приложений и веб-клиента должны идти в одном ритме: общий бэклог, общий API-контракт, релизы по одной канве.

Практический минимум: контракт API фиксируется в OpenAPI до начала работ обоих клиентов, изменения только через версионирование. Если этого нет, каждая правка на сервере ломает один из клиентов, и вы платите за срочные хотфиксы.

Где помогает ИИ для разработки

ИИ для разработки сайта и приложения ускоряет генерацию типового кода, тестов, миграций и текстов интерфейса — по нашей практике на 20–35% на рутинных задачах. ИИ для разработки приложений полезен на повторяющихся слоях: сериализация, обработка ошибок, заготовки экранов по макету. Он не заменяет проектирование схемы данных и не принимает решений о разделении функций: там нужен человек, который понимает и продукт, и ограничения платформ. Ошибка новичков — отдать модели архитектуру целиком и потом три месяца разбирать последствия.

Почему сайт разработки приложений стоит начинать с карты функций

Практика простая: карта функций на одной странице экономит 15–25% бюджета. Разметка «сайт / приложение / оба» до старта стоит два дня аналитика (30–60 тыс. ₽), а переделка уже готового клиента — 400–900 тыс. ₽. Без такой карты команда почти гарантированно построит две параллельные системы, а затем будет платить за их синхронизацию.

Где проекты ломаются на практике

Сайт разработки приложений в отрыве от реальных процессов даёт сбои не в коде, а в стыках: цены, остатки, статусы заказов, доступы сотрудников.

Первая причина — разные цены и остатки. Кто-то из клиентов кеширует каталог на сутки, и клиент видит на сайте одну цену, а в приложении другую. Лечится одним источником данных и инвалидацией кеша по событию.

Вторая — двойная авторизация. Пользователь зарегистрировался в приложении, зашёл на сайт и не может войти. Причина — два независимых хранилища пользователей.

Третья — «у нас есть приложение, давайте сделаем сайт-визитку». В итоге приложение живёт своей жизнью, сайт не приносит трафик, а данные расходятся. Если приложение уже есть, сайт стоит делать как полноценный канал продаж: каталог, SEO-страницы, блог, формы. Про то, как не потерять трафик на старте, читайте в материале SEO-основа сайта.

Частые вопросы

Можно ли начать только с приложения, а сайт сделать потом?

Можно, но дороже. Приложение без веб-клиента лишает вас поискового трафика и десктопных заказов, а API придётся переделывать под веб-сценарии — это 300–600 тыс. ₽ дополнительно. Разумнее сначала выпустить сайт на общем API за 10–16 недель, а приложение добавить вторым этапом.

Нужен ли отдельный бэкенд для приложения?

Нет. Один API на два клиента дешевле и надёжнее: вы поддерживаете одну бизнес-логику вместо двух. Отдельный бэкенд оправдан только при принципиально разной нагрузке или требованиях безопасности, что бывает редко.

Сколько стоит поддержка сайта и приложения вместе?

1,4–2,8 млн ₽ в год при активном развитии: сайт — 40–90 тыс. ₽ в месяц, приложение — 60–180 тыс. ₽ в месяц, инфраструктура — 20–70 тыс. ₽. Общий API снижает сумму на 15–25% по сравнению с раздельными контурами.

Как считать окупаемость двух клиентов?

Считайте не по клиентам, а по выручке на пользователя. Приложение обычно даёт больше повторных покупок и выше LTV, сайт — дешевле привлекает новых. Если суммарный LTV к CAC выше 3, проект окупается за 12–18 месяцев.

Что делать, если сайт и приложение уже расходятся по данным?

Проведите аудит: найдите все места, где данные вводятся или хранятся дважды. Дальше определите один источник правды для каждой сущности и переведите второй клиент на чтение из него. Это 3–6 недель работ и 200–500 тыс. ₽, зато снимает ручную сверку навсегда.

Что делать дальше

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

Дальше — контракт API в OpenAPI и один общий бэклог на оба клиента. Такой проект целиком закрывает команда, которая делает и веб, и мобильные приложения: разработка приложений — это API, два клиента и общая аналитика в одном контуре. Если сомневаетесь, что выгоднее на старте, посмотрите разбор веб-приложение или мобильное.

Статья основана на практике проектов НейроДела и данных Яндекс Вордстата по кластеру «Разработка приложений». Основной запрос материала — «сайт разработки приложений» (3 925 показов в месяц). Если у вас другая ситуация — напишите, разберём.