Почему мобильное приложение — это не только то, что вы видите на экране
Ответ в том, что приложение — это как айсберг. То, что вы видите на экране, это верхушка. Ниже — сервер, база данных, бэкенд, API и ещё десяток вещей, без которых ваши красивые экраны были бы просто картинками, которые ничего не делают.
Вступление
Когда бизнес заказывает мобильное приложение, в голове обычно возникает один образ: экран смартфона с красивым интерфейсом. Кнопки, карточки товаров, корзина, личный кабинет. Всё понятно, всё видно глазами.
Поэтому первое, что удивляет заказчика — это цена. «Подождите, это же просто несколько экранов. Почему так дорого и так долго?»
Ответ в том, что приложение — это как айсберг. То, что вы видите на экране, это верхушка. Ниже — сервер, база данных, бэкенд, API и ещё десяток вещей, без которых ваши красивые экраны были бы просто картинками, которые ничего не делают.
В этой статье объясняем, что находится под водой — простыми словами, без программистского жаргона.
Начнём с простого примера
Представьте, что вы заказали приложение для своей сети кофеен. В нём можно авторизоваться, накапливать баллы, смотреть меню и делать предзаказ.
Вы открываете приложение. Вводите номер телефона. Приложение говорит: «Добро пожаловать, Алексей».
Как оно узнало, что вы — Алексей?
Оно отправило ваш номер телефона на сервер. Сервер заглянул в базу данных, нашёл запись с вашим номером, вернул имя — и приложение отобразило его на экране. Всё это произошло за долю секунды.
Теперь уберите сервер и базу данных. Приложение открывается, вы вводите номер телефона — и ничего не происходит. Некому ответить. Некому посмотреть, кто вы. Красивый экран ввода номера есть. Логики за ним — нет.
Вот что значит «приложение без бэкенда».
Три части любого приложения — и что каждая делает
Когда разработчики говорят о приложении, они делят его на три уровня. Давайте разберём каждый.
Фронтенд — то, что видит пользователь
Это экраны, кнопки, анимации, шрифты, цвета. Всё, с чем пользователь взаимодействует руками. Фронтенд — это лицо приложения.
Именно фронтенд показывают на презентациях и согласовывают с заказчиком. Именно его описывают в техническом задании в виде макетов. Именно его оценивают пользователи в отзывах: «удобное» или «неудобное».
Важно понимать: фронтенд сам по себе ничего не хранит и ничего не считает. Он только отображает то, что получил — и отправляет то, что ввёл пользователь.
Бэкенд — мозг приложения
Бэкенд — это логика. Всё, что происходит «за кулисами» после того, как пользователь нажал кнопку.
Пользователь нажал «оформить заказ» → бэкенд проверил, есть ли товар на складе → рассчитал стоимость с учётом скидки → списал баллы → передал заказ в CRM → отправил push-уведомление пользователю → записал транзакцию в базу данных.
Всё это — бэкенд. Невидимый, но критически важный.
Если фронтенд — это витрина магазина, то бэкенд — это кассир, кладовщик, бухгалтер и менеджер по логистике одновременно.
База данных — память приложения
База данных хранит всё: профили пользователей, заказы, товары, балансы бонусных счетов, историю действий, настройки.
Без базы данных приложение ничего не помнит. Каждый раз, когда пользователь закрывает и открывает его заново — оно начинает с чистого листа. Никакого личного кабинета, никакой истории, никаких сохранённых данных.
Именно поэтому база данных — не опциональный элемент. Любое приложение, которое хранит хоть какую-то информацию о пользователе, работает с базой данных.
«А что, нельзя хранить всё прямо в телефоне?»
Можно — и для некоторых задач это действительно делается. Например, настройки интерфейса или последнее состояние экрана можно хранить локально на устройстве.
Но есть три ситуации, когда локального хранения недостаточно:
Когда данные должны быть у нескольких пользователей. Если клиент сделал заказ в приложении, а менеджер должен увидеть его в CRM — данные должны где-то жить централизованно. Телефон клиента для этого не подходит.
Когда пользователь меняет устройство. Переставил приложение на новый телефон — все данные, которые хранились локально, исчезли. Профиль, история, баллы — всё пропало. Это неприемлемо для любого бизнес-приложения.
Когда нужна безопасность. Хранить чувствительные данные — платёжную информацию, персональные данные, бизнес-логику — прямо на устройстве пользователя опасно. Устройство можно взломать, потерять, передать другому человеку.
Поэтому для любого серьёзного приложения данные живут на сервере.
Сервер — где всё это работает
Бэкенд и база данных должны где-то физически находиться и работать круглосуточно. Это и есть сервер — или, в современных реалиях, облачная инфраструктура.
Сервер — это не просто компьютер в углу офиса. Это:
Постоянная доступность. Ваше приложение должно работать 24 часа в сутки, 7 дней в неделю. Пользователь в 3 ночи делает заказ — сервер должен ответить. Если сервер «упал» — приложение не работает ни у кого.
Масштабирование. Представьте, что вы запустили акцию и за час в приложение зашло в 10 раз больше пользователей, чем обычно. Без правильно настроенной инфраструктуры — сервер не справится, приложение зависнет или упадёт.
Безопасность. Сервер нужно защищать: от взломов, от утечек данных, от DDoS-атак. Это отдельная большая работа.
Затраты. Сервер — это ежемесячные расходы. Аренда облачной инфраструктуры, резервное копирование, мониторинг. Это нужно учитывать в бюджете ещё до старта разработки.
Почему это важно понимать до начала разработки
Есть распространённая история: бизнес приходит к разработчикам с запросом «сделайте нам приложение» и называет бюджет, который покрывает только фронтенд. А когда выясняется, что нужен ещё бэкенд, база данных и сервер — бюджет заканчивается на середине пути.
Результат — незаконченное приложение, которое либо так и не выходит, либо выходит с критическими ограничениями.
Это не проблема разработчиков и не обман. Это проблема ожиданий, которые не совпали с реальностью из-за неполного понимания того, как устроен продукт.
Поэтому правило простое: прежде чем обсуждать дизайн экранов, стоит ответить на вопрос — что должно происходить, когда пользователь нажимает кнопку? Если ответ не «просто открывается следующий экран», а «данные отправляются, проверяются, сохраняются, возвращается результат» — значит, бэкенд нужен. А значит, нужны сервер и база данных.
Как это влияет на стоимость и сроки
Честный ответ: бэкенд часто дороже фронтенда.
Хороший интерфейс на 10 экранов — это несколько недель работы дизайнера и фронтенд-разработчика. Бэкенд для этих же 10 экранов — это проектирование архитектуры, разработка API, настройка базы данных, написание бизнес-логики, тестирование, настройка сервера, настройка безопасности.
Это другие специалисты, другие компетенции, другие сроки.
Грубый ориентир для несложного бизнес-приложения:
- Дизайн и фронтенд — 30–40% бюджета
- Бэкенд и база данных — 40–50% бюджета
- Инфраструктура, тестирование, запуск — 10–20% бюджета
Плюс — ежемесячные расходы на сервер после запуска. Они невелики для небольших приложений, но их нужно закладывать в финансовую модель.
Что можно сделать, если бюджет ограничен
Хорошая новость: необязательно строить всё с нуля. Есть несколько подходов, которые позволяют сократить расходы на бэкенд без потери качества.
BaaS — Backend as a Service. Готовые облачные решения (Firebase, Supabase и другие), которые берут на себя базу данных, авторизацию и базовую бизнес-логику. Подходит для несложных приложений и MVP. Экономит время и деньги на старте, но имеет ограничения по кастомизации.
Готовые интеграции. Платёжные системы, push-уведомления, аналитика — всё это существует в виде готовых сервисов. Не нужно писать с нуля то, что уже сделано.
MVP с минимальным бэкендом. Запустить первую версию с базовым функционалом, собрать обратную связь, потом наращивать. Это экономит деньги и позволяет не строить сложную архитектуру для функций, которые окажутся ненужными.
Любой из этих путей имеет смысл — но только если выбран осознанно, а не потому что «так дешевле и быстрее».
Главное коротко
- Мобильное приложение состоит из трёх частей: фронтенд (экраны), бэкенд (логика) и база данных (память).
- Без бэкенда и базы данных приложение не может ничего хранить, считать или передавать. Это красивая картинка, а не продукт.
- Всё это работает на сервере — и требует ежемесячных затрат на поддержку инфраструктуры.
- Бэкенд часто стоит дороже фронтенда. Это нужно учитывать до старта, а не после.
- Есть способы сократить расходы: BaaS, готовые интеграции, MVP. Главное — выбирать их осознанно.
Планируете разработку приложения и хотите понять реальный объём работ и бюджет до старта? Расскажите о вашей задаче — разберём, что нужно именно для вашего случая, и предложим оптимальную архитектуру.