A guard's alarm signal must reach the dispatcher within 300 milliseconds. Standard push notifications on Android can be delayed by 10 minutes due to Doze Mode — that's unacceptable. We build an architecture where WebSocket is the primary channel (100–300 ms latency) and FCM is the backup. When the panic button is pressed, an assignment is automatically created for the nearest available response group. Incident response time drops from 5–7 minutes to 30–60 seconds, operational expenses for the security company by 25–40%. For an enterprise with 50 sites, savings on dispatcher salaries reach 2 million rubles per year, and route optimization for 200 sites yields up to 1.5 million rubles in fuel savings.
What problems does the app for security companies solve?
It serves three user groups:
- Client: request guard dispatch, object status (secured or disarmed), alarm history, documents (reports, contracts), personal account with rapid response team contacts.
- Guard: patrol checklist with geolocation points, event logging (shift start/end, patrol completed, incident), panic button, communication with dispatcher, navigation to object.
- Dispatcher: real-time map with patrols, incoming alarms, assignment distribution, event log.
Each profile requires different data refresh rates: client — every 5 minutes, dispatcher — less than a second, guard — real-time during movement.
How to guarantee delivery of the alarm signal?
A guard's alarm must reach the dispatcher as quickly as possible. WebSocket (Laravel Broadcasting + Pusher or custom Socket.io) gives 100–300 ms latency. Push via FCM is a backup channel, but FCM does not guarantee delivery in seconds. For client signals (panic button at the site), we add automatic creation of an assignment to the nearest available response group.
As a result, incident response time is reduced from 5–7 minutes to 30–60 seconds. Operational expenses are lowered by 25–40%. For example, savings on dispatcher salaries for an enterprise with 50 sites — about 2 million rubles per year, and on fuel and amortization for 200 sites — up to 1.5 million rubles.
How to solve the background geolocation problem on Android?
A guard must confirm presence in a geo-zone. We use flutter_background_geolocation (commercial plugin) or geolocator in conjunction with foreground service. On Android, without foreground service, background geolocation is killed by Doze Mode — especially on Xiaomi and Huawei. Solution: foreground service + wake lock + onboarding with instructions to disable battery optimization.
Geolocation data is written to PostGIS — this allows building shift trajectory reports and verifying checkpoint circuits via ST_DWithin. Checkpoints are geo-fences on the object map. When the guard approaches within 10 meters — automatic check-in. An NFC tag can be added for additional confirmation via flutter_nfc_kit.
Comparison of approaches on iOS and Android
| Platform | Technology | Background Mode | Peculiarities |
|---|---|---|---|
| Android | Foreground Service + flutter_background_geolocation |
Works with persistent notification | Doze Mode suppresses after 2–3 hours without interaction |
| iOS | Significant-change location service (CLLocationManager) | Limited background work | Requires "always" permission and justification |
Step by step: choose a plugin, configure foreground service with notification, add onboarding to disable battery optimization, set up geo-fences via PostGIS and ST_DWithin, perform stress tests on real devices (Xiaomi, Huawei, Samsung).
What is included in the work
- Requirements analysis and design of three role-based interfaces.
- UX/UI design considering mobile use scenarios.
- Development on Flutter 3.x with feature-first architecture.
- Stress testing of geolocation scenarios on real devices.
- Publication to App Store Connect and Google Play Console.
- Personnel training: guards, dispatchers, clients.
- Technical support for 3 months after launch.
Comparison of Flutter vs Native for Security Companies
| Criteria | Flutter (cross-platform) | Native (Swift + Kotlin) |
|---|---|---|
| Development time | 18–24 weeks (MVP) | 28–36 weeks |
| Cost | Lower by 30–40% | Higher |
| Background geolocation | Requires plugins | Full control on iOS |
Stages and timelines
Analysis → design of three role-based interfaces → UX/UI → development → stress testing of geolocation scenarios → publication → support.
MVP with geo-monitoring of patrols, panic button, and client app — from 18 to 24 weeks. Full system with alarm integration, SIP telephony, and advanced analytics — from 32 weeks. Cost is calculated individually after requirements analysis.
Contact us to evaluate your project — we will prepare a commercial proposal. Order an engineer consultation within 2 hours.