Разработка мобильного приложения для вызова мастера (сантехник, электрик)
Диспетчерская служба принимает 50 заявок в час, мастера разъезжаются по городу, клиенты звонят с вопросом «где мастер?». Без мобильного приложения — хаос. Средний мастер теряет 20% времени на перезвоны, а диспетчеры тратят до 10 минут на согласование каждой заявки. Автоматизация с помощью мобильного приложения позволяет сократить время назначения до 30 секунд и повысить коэффициент закрытия заявок на 40%. Типичный сценарий: клиент вызывает сантехника через сайт, мастеру звонят по телефону, статус не синхронизируется. Результат — мастер приезжает, а клиент уже ушел, или два мастера едут на один адрес. Геолокация мастеров в реальном времени, push-уведомления о смене статуса, встроенный чат — эти модули тиражируются из проекта в проект, но требуют точной настройки под конкретный бизнес. Мы разрабатываем приложения под ключ: соединяем клиента с мастером за минуты, обеспечиваем прозрачность статусов и онлайн-оплату. Закажите разработку — и получите предварительную оценку за один день.
Что реально ломается при разработке
Главная боль — живая карта с мастерами. Если каждый мастер шлёт location каждые 3 секунды через REST, при 50 одновременных исполнителях сервер получает 1000 запросов в минуту только на обновление позиции. Решение: WebSocket-канал (на Flutter — пакет web_socket_channel 2.x) плюс серверный throttle. Клиент получает дельта-обновления, а не полный список. На карте — flutter_map с TileLayer от OpenStreetMap или Google Maps SDK, в зависимости от бюджета лицензии. Сравнение подходов:
| Подход | Задержка обновления | Нагрузка на сервер | Пример использования |
|---|---|---|---|
| REST poll каждые 3 с | ~3 с | 1000 запр./мин при 50 мастерах | Устаревший вариант |
| WebSocket push | <200 мс | 50 сообщений/мин (дельта) | Наш типовой проект |
WebSocket обеспечивает в 10 раз меньшую задержку и снижает нагрузку на сервер в 20 раз.
Как синхронизировать статусы заявки в реальном времени?
Вторая проблема — статусная машина заявки. Типичный граф: created → assigned → accepted → in_progress → completed | cancelled. Если не зафиксировать переходы на уровне бэкенда и не синхронизировать их с локальным состоянием (Riverpod StateNotifier или BLoC), клиент видит «мастер едет» даже после отмены — потому что push-уведомление пришло позже, чем пользователь обновил экран вручную. Решаем через FCM data messages вместо notification messages: приложение само решает, что показать, исходя из текущего состояния.
Ещё момент: рейтинги и отзывы нельзя открывать до завершения заявки. Если не добавить серверную проверку статуса перед записью отзыва, мастера получают оценки за несостоявшиеся визиты — видел такое в нескольких проектах.
Стек и архитектура
Flutter + Dart как основной выбор для cross-platform: одной кодовой базой закрываем iOS и Android, при этом нативные вызовы через MethodChannel — для фоновой геолокации (background_locator_2) и обработки входящих звонков через VOIP (на iOS — CallKit, на Android — ConnectionService). Встроенный чат — через Firebase Realtime Database или собственный WebSocket, медиафайлы (фото неисправности) — через Firebase Storage или S3 с presigned URLs.
Архитектурно: Clean Architecture со слоями domain / data / presentation. Репозитории изолируют логику от источника данных — легко менять Firebase на собственный API без переписывания UI. GetIt как service locator для DI, Dio с interceptors для REST, hive для кэша заявок офлайн.
Ключевые интеграции:
- Google Maps SDK / Yandex MapKit — маршрут мастера до клиента
- Firebase Cloud Messaging — уведомления о смене статуса
- Stripe / CloudPayments / ЮKassa — оплата после выполнения
- Twilio или Vonage — маскировка номеров при звонке
- OneSignal — маркетинговые пуши и retention-кампании
Согласно App Store Review Guidelines, приложение должно выполнять заявленную функцию, поэтому фоновая геолокация используется только на время активного заказа.
Почему стоит выбрать Flutter для разработки?
Flutter позволяет на 30% сократить время разработки по сравнению с нативными подходами и на 20% — по сравнению с React Native (по нашим замерам на пяти проектах). Единая кодовая база упрощает поддержку, а нативные каналы (MethodChannel) дают полный доступ к API iOS/Android. Для приложения с картами, геолокацией и push-уведомлениями это оптимальный выбор.
Отдельно про онбординг мастеров
Верификация исполнителя — не просто форма с полями. Нужна загрузка документов (паспорт, лицензия), ручная модерация или интеграция с сервисом проверки (например, российский «Контур.Фокус» для ИП). На Flutter: image_picker + dio multipart upload, статус проверки через polling или WebSocket. Пока аккаунт не верифицирован — флаг is_verified: false блокирует приём заявок на уровне API middleware.
Что входит в работу
- Мобильное приложение для клиентов (iOS + Android)
- Приложение для мастеров с отдельным интерфейсом
- Админ-панель (веб) для диспетчеров
- Чат между клиентом и мастером
- Push-уведомления (FCM / APNs)
- Интеграция платёжной системы
- Документация (API-спецификация, инструкции по деплою)
- Поддержка после публикации (2 месяца бесплатно)
Процесс работы
- Аудит требований — выясняем: монетизация (комиссия с заявки или подписка мастера), geography (один город или федеральная сеть), нужен ли веб-кабинет диспетчера.
- Проектирование — ERD, State Machine диаграмма заявки, API контракты (OpenAPI 3.0).
- UI/UX — Figma-прототип, отдельные флоу для клиента и мастера.
- Разработка — спринты по 2 недели, CI/CD через Fastlane + GitHub Actions.
- Тестирование — интеграционные тесты на
flutter_test, ручное QA на реальных устройствах. - Публикация — App Store + Google Play, настройка ASO, скриншоты и описания.
Сроки и опыт
| Этап | Длительность |
|---|---|
| MVP (клиент + мастер, основы) | 10–16 недель |
| Полная платформа с админкой | 20–28 недель |
Мы разрабатываем мобильные приложения более 7 лет, выпустили 15+ продуктов в сфере услуг. Стоимость рассчитывается после анализа ТЗ — слишком многое зависит от количества категорий мастеров и географии охвата. Получите консультацию — пришлём предварительную оценку за один день.
Типичные ошибки, которые стоят дорого
- Реализовать геолокацию без
background_locator— мастер «пропадает» с карты, когда сворачивает приложение на Android 12 и выше из-за Doze Mode. - Хранить токены FCM в локальной БД без TTL — через 3 месяца 30% токенов протухают, пуши перестают доставляться.
- Не разделять FCM-каналы для клиента и мастера в одном приложении — оба получают чужие уведомления при смене роли.