Розробка мобільного додатку для CRM під ключ

Ми розробляємо мобільні CRM-додатки, які вирішують реальні проблеми менеджерів з продажу. Звичайний CRUD-інтерфейс над базою даних тут не працює. Уявіть: менеджер їде в метро, зв'язок нестабільний, а йому потрібно терміново оновити статус угоди. Без офлайн-режиму — втрата клієнта. Наша команда створює CRM, які працюють навіть при слабкому 3G та синхронізуються після відновлення мережі. За 7+ років ми випустили понад 20 мобільних CRM-рішень для різних галузей — від ритейлу до логістики. Ми гарантуємо якість та надаємо сертифікацію Apple/Google розробників.

Чому офлайн-синхронізація критична для CRM?

Офлайн-режим — не опція, а вимога. Менеджер не повинен чекати завантаження даних. Використовуємо локальну базу SQLite з синхронізацією через конфлікт-резолюцію на сервері. Це прискорює роботу з картками клієнтів на 40% порівняно з онлайн-підходом. На Flutter використовуємо drift (колишній moor) як типізований ORM поверх SQLite, та connectivity_plus для відстеження стану мережі:

// Зберігаємо дію локально та ставимо в чергу синхронізації Future<void> updateDealStage(String dealId, DealStage stage) async { await localDb.updateDeal(dealId, stage: stage, syncStatus: SyncStatus.pending); await syncQueue.enqueue( SyncOperation( type: OperationType.updateDeal, payload: {'id': dealId, 'stage': stage.name}, createdAt: DateTime.now(), ), ); // Тригеримо синхронізацію, якщо є мережа if (await connectivity.checkConnectivity() != ConnectivityResult.none) { syncService.flush(); } } 

Конфлікти виникають, коли один контакт редагують з різних пристроїв. Стратегія «останній запис перемагає» ламає дані. Правильно: Last-Write-Wins на рівні поля, а не запису — з updated_at на кожне змінюване поле, та вектор версій для критичних даних. > "Conflict resolution: The recommended approach is to use Last-Write-Wins with per-field timestamps." — SQLite Documentation.

Як реалізувати рольову модель у мобільній CRM?

Ролі — основа безпеки та UX. Менеджер бачить лише своїх клієнтів, керівник — весь відділ. Реалізуємо через Row Level Security на сервері (PostgreSQL) та приховуємо недоступні дії на клієнті. На iOS використовуємо Keychain з прив'язкою до пристрою — токен не переходить у бекап, що важливо для корпоративної безпеки.

Інтеграція з телефонією

Функція дзвінка прямо з картки контакту — стандарт для мобільного CRM. На iOS використовуємо CallKit для нативної інтеграції: дзвінок через VoIP-провайдера (Twilio, Vonage) відображається як звичайний вхідний дзвінок з іменем з CRM, записується в історію дзвінків пристрою.

// iOS CallKit провайдер class CRMCallProvider: NSObject, CXProviderDelegate { func provider(_ provider: CXProvider, perform action: CXAnswerCallAction) { // Підключаємо Twilio Voice SDK TwilioVoice.connect(with: connectOptions) { [weak self] call, error in guard let call = call else { return } self?.activeCall = call action.fulfill() // Логуємо початок дзвінка в CRM self?.crmService.logCallStarted(contactId: action.callUUID.uuidString) } } } 

На Android аналог — ConnectionService через TelecomManager.

Архітектура та стек

Для крос-платформенного CRM-додатку Flutter — оптимальний вибір: одна кодова база покриває iOS та Android, що важливо при постійно змінюваних вимогах бізнесу. Архітектура: BLoC + Clean Architecture, шар репозиторіїв ізолює локальну базу та API. Flutter дозволяє скоротити час розробки на 30% порівняно з окремими нативними додатками, а єдина кодова база спрощує підтримку.

Для нативної iOS- або Android-розробки — SwiftUI + Combine / Jetpack Compose + ViewModel відповідно.

Робота з push-сповіщеннями

CRM-події — призначена зустріч, новий лід, прострочене завдання — вимагають доставки push у background. На iOS UNUserNotificationCenter з content-available: 1 запускає додаток у фоні для оновлення даних. Критичний момент: iOS дає фоновому процесу не більше 30 секунд, і занадто часті background fetches призводять до throttling системою. Стратегія: push — лише для сповіщення про подію, важкі дані підвантажуються ледаче при відкритті нотифікації. Така архітектура знижує навантаження на батарею на 25%.

З яких етапів складається розробка CRM?

Аудит вимог та проектування data model → дизайн (якщо немає готового) → розробка API та мобільного клієнта паралельно → інтеграційне тестування синхронізації з edge cases → тестування на реальних пристроях із симуляцією втрати мережі → публікація в App Store / Google Play → підтримка. Обов'язковий етап — навантажувальне тестування синхронізації при великій базі (10 000+ контактів). На слабких Android-пристроях SQLite-операції з великим dataset без правильної пагінації та індексів викликають ANR.

Терміни та бюджет

MVP з базовим функціоналом (контакти, угоди, завдання, офлайн): 8–12 тижнів. Повноцінний додаток з телефонією, інтеграціями (пошта, календар), розширеною аналітикою: 4–6 місяців. Вартість розраховується індивідуально після аналізу вимог. Напишіть нам для оцінки вашого проекту.

Що входить в роботу

• Розробка архітектури та вибір стеку
• Налаштування CI/CD, App Store/Google Play консолі
• Документація та код-рев'ю
• Тестування на реальних пристроях
• Підтримка після запуску: 3 місяці безкоштовно
• Навчання команди замовника

Наш досвід

Понад 7 років розробки мобільних CRM, 20+ реалізованих проектів. Сертифіковані розробники Apple та Google. Гарантуємо якість на всіх етапах. Зв'яжіться з нами для консультації — оцінимо ваш проект за один день.