Розроблення мобільного додатку для охоронної компанії
Додаток охоронної компанії — це не просто CRM з нарядами. Це система, де затримка push-сповіщення на 30 секунд може означати справжній інцидент без реакції. Надійність доставки сигналів тривоги та геолокаційний контроль нарядів — ось що визначає архітектурні рішення.
Три контури системи
Додаток охоронної компанії як правило обслуговує три групи користувачів з різними потребами:
Клієнт (замовник охорони): запит на виклик охорони, статус об'єкту (охороняється/знято), історія тривог, документи (акти, договори), особистий кабінет з контактами групи швидкого реагування.
Охоронець на об'єкті: чек-лист обходу з геолокаційними точками, фіксація подій (початок/закінчення смін, обхід виконаний, інцидент), тривожна кнопка, зв'язок з диспетчером, навігація до об'єкту.
Диспетчер: карта з поточними нарядами в реальному часі, вхідні тривоги, розподіл нарядів, журнал подій.
Три окремі інтерфейси — але один бекенд та, при бажанні, один Flutter-додаток з перемиканням профілю.
Геолокація та моніторинг нарядів — технічно найскладніше
Охоронець на об'єкті має періодично підтверджувати свою присутність у призначеній геозоні. Реалізуємо через фонову геолокацію: flutter_background_geolocation (комерційний плагін, але єдиний надійний для iOS + Android з фоновим режимом) або geolocator зі foreground service.
На Android без foreground service з постійним сповіщенням фонова геолокація гине в Doze Mode приблизно на третій годині смін — особливо на Xiaomi та Huawei з агресивними політиками енергозбереження. Це не теоретичний ризик: ми з цим стикнулися при розробці додатку для охорони торгових центрів. Рішення — foreground service + wake lock + білий список у налаштуваннях батареї (з онбордингом, який пояснює користувачу, що слід зробити).
Дані геолокації охоронця пишуться в PostGIS (PostgreSQL) — дозволяє будувати звіти за траєкторією смін, верифікувати факт обходу точок маршруту через ST_DWithin.
Точки обходу — це геозони на карті об'єкту. При підході охоронця на 10 метрів — автоматична відмітка. Можна додати NFC-метку на фізичній точці для додатково підтвердження (через flutter_nfc_kit).
Тривожна кнопка
Тривога від охоронця повинна дійти до диспетчера максимально швидко. WebSocket (Laravel Broadcasting + Pusher або власний Socket.io) — затримка 100–300 мс у нормальних умовах. Push через FCM — резервний канал, але FCM не гарантує доставку в секунди.
Для клієнтського тривожного сигналу (паніч-кнопка на об'єкті) — те ж саме, плюс автоматичне створення наряду на найближчу вільну групу реагування.
Інтеграції
- Інтеграція з системами сигналізації (Bolid, С2000) через API охоронного пульту — якщо ЧОП хоче бачити у додатку статус датчиків
- Телефонія через SIP (linphone_sdk) — зв'язок диспетчера з охоронцем без виходу з додатку
- Генерація актів та нарядів у PDF за шаблоном
Стек
Flutter 3.x + Clean Architecture (feature-first), Laravel 10 + WebSocket, PostgreSQL + PostGIS, FCM, Redis для real-time даних.
Етапи та терміни
Аналіз → проектування трьох ролевих інтерфейсів → UX/UI → розроблення → стресс-тестування геолокаційних сценаріїв → публікація → підтримка.
MVP з геомоніторингом нарядів, тривожною кнопкою та клієнтським додатком — від 18 до 24 тижнів. Повна система з інтеграцією сигналізації, SIP-телефонією та розширеною аналітикою — 32+ тижні.
Вартість розраховується індивідуально після аналізу вимог.







