Мобильное приложение, которым реально пользуются, — а не такое, что пылится в сторе.
Мобильные приложения и Progressive Web Apps из Германии — как честный канал в реальном процессе: клиентское приложение, приложение для выездных бригад, бронирование и self-service, внутренние мобильные процессы или companion-приложение к продукту. С чётким выбором между PWA и React Native, аккуратным MVP-скоупом, интеграцией с backend, авторизацией, push, offline и реальным путём в стор. Founder-led из Крефельда.
- PWA · React Native · Expo · TypeScript · Node / .NET backend
- Релиз в App Store / Play Store, в том числе review-раунды
- База в Крефельде · Германия и EU · GDPR-аккуратность
Когда мобильное приложение — реальная инвестиция, а когда нет.
Иконка на домашнем экране — это не маркетинговый трофей. Приложение оправдывает себя, когда есть повторяющийся сценарий, который мобильно работает заметно лучше, чем вкладка в браузере: заказы для выездного сервиса, запись и бронирование, программа лояльности, документация на объекте, статусы для клиента, companion к физическому продукту. Если этот сценарий не ясен, нативное приложение почти всегда — неверный ответ, а хорошее веб-приложение или Progressive Web App (PWA) — лучший первый шаг. Поэтому p24.co планирует мобильные проекты «с конца»: сначала сценарий, потом вопрос «PWA или React Native», потом скоуп MVP. На выходе — канал, которым реально пользуются, а не «приложение для галочки».
Типичные сценарии для мобильного приложения или PWA.
Мы видим шесть ситуаций, где мобильный канал — как приложение или как PWA — даёт наибольший рычаг. Если узнаёте себя в одной из них — вы по адресу:
Клиентское приложение: self-service, бронирование, статус
Клиент бронирует визит, оформляет заявку, отслеживает статус, прикладывает документы, смотрит свой договор. Лёгкое приложение или PWA с понятным логином, аккуратными push-уведомлениями и стабильным backend убирает три цикла переписки на одну задачу.
Приложение для выездных бригад и сервиса
Монтажники, техники, сервис, инспекторы, продажи в полях: открыть задание, внести данные, загрузить фото и подпись, списать материалы. Работа offline и контролируемая синхронизация с ERP- или заказным backend, когда сеть возвращается.
Приложение для бронирования и self-service
Запись, слоты, столы, кабинеты, курсы, консультации — с календарём, листами ожидания, push-напоминаниями и оплатой. Канал, который клиенты реально открывают, а не PDF-форма, которую заполняют один раз в году.
Внутренние мобильные процессы
Сотрудники фиксируют часы, повреждения, приёмку, чек-листы, обходы по безопасности с телефона. Мобильное приложение снимает нагрузку с офиса — и аккуратно заменяет планшет с бумагой и переписку «в Telegram начальнице».
Companion-приложение к продукту или устройству
Устройство, датчик, оборудование, автомобиль — и приложение, которое отвечает за настройку, живые данные, диагностику, обновления и уведомления. Здесь приложение — не «приятное дополнение», а часть продукта.
MVP приложения для нового продукта
У вас есть идея, которая должна жить на мобильном, и вы хотите проверить её, не вливая девять месяцев и четверть миллиона евро в «полную версию». Мы делаем аккуратный MVP на нескольких ключевых сценариях — обычно на React Native или как PWA — с понятной дорожной картой дальше.
Гайд по решению: PWA vs. React Native vs. нативная app.
Самое важное решение принимается не в коде, а до него. Эти шесть пунктов мы проходим вместе с вами до первой строки кода — и они определяют половину дальнейших затрат:
Кто аудитория и как часто она открывает приложение?
Несколько редких визитов в год (проверить статус, подать заявку, забронировать) — почти всегда PWA: без барьера стора, без скачивания, без трения от обновлений. Ежедневная интенсивная работа с реальным вовлечением (выездной сервис, лояльность, ежедневные процессы) почти всегда оправдывает настоящую app на React Native.
Насколько глубоко нужно лезть в устройство и железо?
Чистые UI- и API-сценарии сегодня отлично живут в PWA. Как только нужны камера, NFC, Bluetooth, фоновая геолокация с точностью, нативные уведомления, health- или filesystem-API — React Native (и в крайних случаях нативный слой) более честный инструмент.
Насколько важны App Store и Play Store как канал?
Если видимость в сторе, отзывы и «найдите нас в App Store» имеют значение — например, для потребительского приложения, программы лояльности или companion к продукту — приложению место в сторе. Для внутренних и B2B-процессов стор чаще создаёт трение, чем ценность; тогда чище — PWA плюс внутренний канал распространения.
Offline: приложение обязано работать без сети?
Выездной сервис, промышленность, логистика, объекты без покрытия — offline не обсуждается. React Native (с локальной БД вроде SQLite или WatermelonDB и продуманным слоем синхронизации) здесь, как правило, надёжнее. Современная PWA тоже умеет offline, но потолок для глубокого offline ниже.
Команда, время, бюджет — что вы реально потянете?
Две нативные кодовые базы (iOS + Android) плюс web — это дорого и медленно в итерации. React Native + Expo даёт одну кодовую базу для iOS и Android и обычно заметно лучший time-to-market. PWA ещё быстрее и дешевле — если задачи под неё подходят.
Насколько плотно приложение завязано на ваш backend?
Приложение настолько хорошо, насколько хорош backend за ним. Если авторизация, данные, роли, бронирования и уведомления и так создаются заново — мы планируем app и backend вместе. Если ERP/CRM/SaaS уже есть — заранее фиксируем, что делает приложение, что backend, а что сторонняя система. До того, как кто-то нарисовал экран.
Блоки, стек и архитектура — что именно вы получаете.
Мобильное приложение от p24.co — это не «лого + три экрана + какой-то API». Каждый блок сознательно проектируется, документируется и передаётся:
1. Discovery и решение по стеку
Сценарий, аудитория, устройства, потребности в offline и push, стратегия стора, существующие системы. Результат: честная рекомендация «PWA vs. React Native vs. native», скоуп MVP, список рисков и допущений — до первой строки кода.
2. Архитектура: React Native + Expo или PWA
Для нативных приложений: React Native с Expo, TypeScript, типизированные API-клиенты, чистая навигация, тема, модульная структура. Для PWA: Next.js / React с service worker, manifest, установка, поддержка push, реальный offline-кэш.
3. Интеграция с backend и синхронизация
Слой API (REST или tRPC/GraphQL), интеграция с существующим backend или сборка нового (Node, .NET, Postgres). Чистая модель данных, идемпотентность, реальная стратегия разрешения конфликтов для offline-синхронизации. Созданное локально аккуратно поднимается наверх при следующем выходе в сеть.
4. Авторизация, роли и безопасные сессии
Логин по email/паролю, magic link, OAuth/SSO или single-tenant токен. Роли и видимость (клиент, сотрудник, админ), безопасное хранение токенов (Keychain/Keystore), инвалидизация сессий, по необходимости — биометрия.
5. Push-уведомления и inbox
Push через Expo Notifications, APNs/FCM или web push. Чистый opt-in, сегментированная рассылка, шаблоны, in-app inbox с пометками прочитанного, правила против спама. Уведомления, которые пользователь действительно хочет, а не 14 штук в день, потому что в маркетинг-консоли есть кнопка «отправить».
6. Offline и локальные данные
Локальный кэш и при необходимости локальная БД (SQLite, WatermelonDB, MMKV), очереди действий, чёткие правила разрешения конфликтов, прозрачные индикаторы UI («синхронизируется»). Приложение не падает, когда пропадает сеть.
7. Аналитика, crash-reporting и feature flags
Бережная к данным аналитика (Plausible, PostHog или собственная), crash- и error-reporting (Sentry), feature flags для контролируемых раскаток. Вы видите, что реально происходит, — а не только когда переполняется поддержка.
8. Релиз в App Store / Play Store и распространение PWA
Иконки, splash, store-листинги (DE/EN), скриншоты, тексты по приватности, privacy-манифест, in-app покупки где нужно, App Tracking Transparency. Мы ведём review-раунды Apple и Google. Для PWA — корректная установка, web manifest, опциональный внутренний канал.
9. Документация и передача
Архитектурный документ, обоснование стека, контракты API, гайд по сборке и релизу, аккуратная передача credentials стора вам, документация для онбординга разработчика. Новый инженер — или новый подрядчик — выходит на работу за дни.
От MVP приложения до дорожной карты — процесс.
Мобильные проекты почти всегда умирают в одной точке: слишком много в первом релизе и никакого плана дальше. Мы идём фазами — с реальным MVP, быстрой pilot-фазой и контролируемой раскаткой.
- 01
Discovery и скоуп MVP
Неделя 1–2Карта процесса, аудитория, приоритизированные use case-ы, решение PWA vs. React Native, эскиз модели данных, допущения и non-goals. Результат: компактный mobile-бриф, скоуп MVP на 1–2 ключевые journey, список рисков и оценок.
output → Mobile-бриф · скоуп MVP - 02
Дизайн и кликабельный прототип
Неделя 2–4UX-флоу ключевых journey, wireframes, кликабельный прототип в Figma, набор стилей и компонентов. Тестируем с реальными пользователями или внутренними стейкхолдерами. Изменения происходят здесь — не позже в коде.
output → Прототип · дизайн-система - 03
Сборка MVP (React Native или PWA)
Неделя 4–10Реализация ключевых journey, слой API, авторизация, локальные данные, push, аналитика, crash-reporting. Еженедельные демо и сборки в TestFlight / Play Internal / PWA staging.
output → Сборка MVP · TestFlight / Play Internal - 04
Pilot с реальными пользователями
Неделя 10–12Контролируемый pilot на выбранной группе: первые клиенты, одна выездная бригада, один объект. Включена телеметрия, налажен канал обратной связи, ежедневные циклы багфиксов и UX-полировки. То, что мы узнаём здесь, ценнее трёх внутренних встреч.
output → Pilot · цикл багфиксов и UX-полировки - 05
Релиз в стор / раскатка PWA
Неделя 12–14Листинги в App Store и Play Store, review-раунды, privacy-манифест, тексты по приватности. Для PWA — корректная установка и, где нужно, внутренний канал. Стабильная первая версия на устройствах реальной аудитории.
output → Релиз в стор · раскатка PWA - 06
Эксплуатация, итерации и дорожная карта
с 14-й неделиGo-live, телеметрия и краш-репорты активны, налажен support- и update-процесс. Дальше — короткие циклы итераций по дорожной карте: следующие journey, новые платформы, новые модули — на основе реальных данных использования.
output → Живая эксплуатация · setup дорожной карты
Что значит «хорошо» для мобильного приложения на практике.
Хорошее приложение узнают не по splash-экрану, а по тому, что остаётся после трёх недель реального использования. Наша планка:
Его реально открывают
Приложение ценно только если его открывают после онбординга. Мы проектируем под один ясный, повторяющийся повод — а не под двенадцать функций, которыми никто не пользуется.
Быстро, спокойно, без рывков
Холодный старт меньше двух секунд на реальном железе, плавный скролл списков, переходы ощущаются нативно. Без искусственных loader-ов, белых экранов и «театра анимаций», прикрывающего медленный API.
Offline — не ошибка
Действия пишутся в локальную очередь, чётко помечаются «синхронизируется» и автоматически уходят наверх, когда возвращается сеть. Конфликты разрешаются, а не молча проглатываются.
Авторизация надёжна и не мешает
Логин работает с реальными менеджерами паролей, с биометрией где уместно, с magic link где это удобнее. Сессии хранятся безопасно, «выйти» действительно означает выход, обновление токена незаметно.
Push уважает пользователя
Чёткий opt-in, понятные правила частоты, сегментированные шаблоны. Приложение не шлёт 14 пушей в день из-за того, что у маркетинг-инструмента есть кнопка — это самый быстрый путь к удалению.
Обновления и review в сторе — решённая задача
Релизы воспроизводимы, OTA-обновления (где разрешены) сокращают время реакции, обзоры в сторах ведутся с реальными release notes — а не «отправим в Apple и будем надеяться».
Приватность, данные и ответственность основателя.
Мобильное приложение находится в телефонах ваших клиентов или сотрудников — оно ближе к реальным данным, чем почти любое другое ПО. p24.co управляется Димитрием Кронихом из Крефельда. Вы получаете прямого технического собеседника с европейской базой, который реально берёт ответственность за архитектуру, безопасность и приватность, а не делегирует их вниз.
- 01Ответственность на уровне основателя — прямой контакт с человеком, который принимает решения по архитектуре и приватности.
- 02База в Крефельде · Германия и EU — GDPR-аккуратность, EU-хостинг backend, прозрачные основания обработки.
- 03Бережная к данным телеметрия, прозрачные privacy-манифесты, корректно реализованный App Tracking Transparency.
- 04Безопасное хранение токенов и ключей (Keychain/Keystore), чёткие правила авторизации и сессий.
- 05Передача такая, чтобы вашу app мог продолжать вести и другой подрядчик — без замка на руках.
Часто задаваемые вопросы о разработке мобильных приложений и PWA.
PWA или нативное приложение — что выбрать?
Зависит от трёх вещей: как часто пользователи открывают приложение, насколько глубоко нужны функции устройства (камера, Bluetooth, push, offline) и насколько важны App Store и Play Store как канал. Для редких, не самых требовательных сценариев почти всегда честнее PWA. Для ежедневного интенсивного использования, жёстких требований к offline или реальной интеграции с устройством обычно лучше React Native.
Почему React Native, а не «настоящие нативные» Swift и Kotlin?
Потому что одна кодовая база для iOS и Android в 90 % бизнес- и MVP-кейсов заметно дешевле, быстрее и удобнее в поддержке. React Native + Expo сегодня даёт качество UI и производительности, которого хватает для подавляющего большинства приложений. Нативные стек (Swift/Kotlin) мы оставляем для краевых случаев: глубокая интеграция с железом, очень высокие требования к производительности, собственные нативные модули.
Сколько на самом деле стоит MVP приложения?
Честно собранный MVP приложения или PWA с 1–2 ключевыми journey, backend, авторизацией, push и путём в стор/раскатки обычно укладывается в средний-верхний пятизначный диапазон евро. Более крупные проекты с большим offline, несколькими ролями, сложным backend и длинной дорожной картой быстро уходят в шестизначный. Мы открыто фиксируем scope, допущения и риски — без «фикспрайсов» поверх половинчатых требований.
Сколько времени до первой версии в сторе?
Реалистичный коридор для MVP — 10–14 недель от discovery до первого релиза в сторе, в зависимости от scope, объёма backend и review-циклов Apple и Google. PWA-версия той же идеи обычно выходит на 4–6 недель быстрее, поскольку review стора не требуется.
Работает ли приложение offline и как синхронизируется с backend?
Да. Для приложений, где offline важен, мы используем локальное хранилище (SQLite, WatermelonDB или MMKV), пишем действия в очередь и контролируемо синхронизируемся с backend, как только возвращается сеть. Конфликты обнаруживаются и разрешаются по понятным правилам, а не молча перезаписываются.
Push, App Store, приватность — кто берёт на себя релизный ад?
Мы. Аккаунты Apple и Google developer ведём вместе с вами, дальше — store-листинги, privacy-манифесты, тексты по приватности, скриншоты, App Tracking Transparency и review-раунды. Вам не нужно сначала осваивать App Store Connect и Play Console.
Что будет после запуска — вы продолжаете поддерживать приложение?
По запросу мы берём эксплуатацию: мониторинг (краш-репорты, телеметрия), багфикс-релизы, обзоры в сторах, итерации по дорожной карте, новые модули. Точно так же после MVP вы можете перевести проект на собственную команду — мы передаём документацию и сетап так, чтобы этот путь оставался реальным.
Что с приватностью, GDPR и данными в Германии?
Backend-компоненты по умолчанию хостим в EU (Hetzner, AWS Frankfurt, Azure West Europe). Персональные данные чётко отделяем, обработки документируем, на стороне приложения используем бережную к данным телеметрию и прозрачные privacy-манифесты. Блоки для договоров обработки данных готовы.
Можете ли вы перехватить или «спасти» существующее приложение?
Да — это один из наших типичных кейсов. Мы начинаем с аудита текущей кодовой базы и архитектуры, фиксируем состояние, называем риски и предлагаем путь: точечный рефакторинг, поэтапная миграция на чистый стек или — где это честнее — открытая пересборка с понятным планом миграции данных.
Связанные услуги и темы
Давайте честно проверим вашу идею приложения.
Коротко расскажите, для кого приложение, какой процесс оно реально обслуживает и каких систем должно касаться. Получите честную, техническую оценку — включая рекомендацию PWA или React Native — напрямую от основателя, без продажного слоя и без buzzword-ов.