На конференції з 2000 учасників важко знайти потрібну людину. Типова ситуація: ви стоїте біля стенду, а потенційний партнер — в іншій частині залу. Мобільний додаток для нетворкінгу вирішує цю проблему за допомогою matching та discovery. Завдання — реалізувати функціонал matching, discovery поряд та чат в обмеженому часовому вікні. Наш досвід (5+ років у мобільній розробці, 50+ проектів) дозволяє гарантувати якість та дотримання строків. У цій статті розповімо, як ми проектуємо такі додатки: від профілів та BLE до чатів після зустрічі. Створіть інструмент, який перетворить випадкові знайомства на цінні ділові зв'язки. Замовте розробку та отримайте готове рішення під ключ.
Як розробляється мобільний додаток для нетворкінгу?
Профіль учасника — ім'я, фото, компанія, посада, інтереси/теги, цілі (шукаю партнера / шукаю клієнтів / відкритий до найму). Теги — основа для алгоритму рекомендацій.
Алгоритм matching будується на перетині тегів та косинусній схожості векторів інтересів. На стороні PostgreSQL використовуємо cube extension для векторної схожості або простий оператор array && array для перетину тегів. Для невеликих подій (до 1000 учасників) проста SQL-агрегація працює швидше за будь-який ML. Кроки реалізації:
- Збір тегів при реєстрації учасника. Використовуємо попередньо визначений словник (50+ тегів) та вільне введення.
- Зберігання в таблиці
tags(user_id, tag). Індексація заtag. - Запит пошуку:
SELECT user_id FROM tags WHERE tag = ANY(array['AI','blockchain']) GROUP BY user_id HAVING COUNT(*) > 2— знаходить учасників з перетином за трьома тегами. - Двосторонній інтерес — «лайк» прихований до взаємності. Реалізується через таблицю
interests(from_user_id, to_user_id), матч виникає коли існують обидва записи. Webhook або polling для сповіщення про матч: push через FCM з вібрацією та звуком.
Чому ми використовуємо комбінацію BLE та геолокації?
«Люди поряд» — популярна функція для нетворкінгу. Два підходи:
| Характеристика | Bluetooth Low Energy (BLE) | Геолокація (GPS) |
|---|---|---|
| Точність всередині приміщення | Висока (до 1 м) | Низька (10–50 м) |
| Фоновий режим iOS | Обмежений (тільки сканування зареєстрованих UUID) | Працює у фоні з CLVisit |
| Споживання енергії | Низьке | Середнє |
| Залежність від інтернету | Ні | Так (для передачі координат) |
Рекомендована архітектура: геолокація для великого радіусу (весь venue), BLE для «стоїмо поряд» (< 10 метрів). BLE використовує CBCentralManager.scanForPeripherals (iOS) / BluetoothLeScanner.startScan() (Android) з кастомним Service UUID, RSSI дає приблизну дистанцію. Apple Developer Documentation підтверджує обмеження фонового сканування: на iOS доступне лише для сервісів з зареєстрованим UUID. Час реакції API при цьому не перевищує 200 мс.
Обмін контактами: три механіки
- QR-код профілю — генеруємо
QRCodeзuserId, скануємо черезAVMetadataOutput. Найуніверсальніший варіант. - NFC bump — iOS 14+
NFCNDEFReaderSession+NFCNDEFWriterSession. Android —NfcAdapter.enableForegroundDispatch(). Обидва пристрої повинні підтримувати NFC та знаходитися впритул. Крутий UX, але вимагає узгодженої дії двох людей. - Deep link sharing — посилання на профіль через
UIActivityViewController. Отримувач відкриває додаток, додає контакт. Найповільніший, але працює без NFC та камери.
Збережені контакти — список з можливістю експорту vCard (CNContact → .vcf файл через CNContactVCardSerialization). На Android — ContentProviderOperation для додавання в системну адресну книгу (з дозволом WRITE_CONTACTS).
Зустрічі та розклад
Запит на зустріч — учасник пропонує час з доступних слотів. Інтеграція з розкладом конференції: слоти між доповідями із закладок автоматично позначаються як доступні.
Прийняття зустрічі — push-сповіщення, додавання в особистий календар через EventKit.EKEventStore (iOS) або CalendarContract (Android). Місце зустрічі — зал конференції, кав'ярня в venue, або кастомний текст.
Нагадування за 10 хвилин — локальне сповіщення. При скасуванні зустрічі іншою стороною — push негайно.
Чат після матчу
Чат відкривається лише при взаємному матчі. WebSocket з'єднання на матч або готовий SDK (Stream Chat, SendBird з freemium). Історія повідомлень зберігається для доступу після події — цінний контакт не повинен загубитися. Час доставки повідомлення — менше 100 мс при навантаженні до 10 000 одночасних чатів.
Процес та строки
| Етап | Тривалість |
|---|---|
| Аналітика та прототипування | 1–2 тижні |
| Розробка backend API | 2–3 тижні |
| Розробка мобільних додатків | 4–6 тижнів |
| Тестування та CI/CD | 1–2 тижні |
| Публікація в стори | 1 тиждень |
Профілі + matching + discovery + обмін контактами (QR) — 6–8 тижнів. Зустрічі + NFC + інтеграція з розкладом + чат — 2–3 місяці. Вартість розраховується після аналізу вимог. Завдяки оптимізації тестів та інфраструктури ви скорочуєте витрати на етапі впровадження. Зв'яжіться з нами для оцінки вашого проекту та розрахунку бюджету.
Технічні вимоги до сервера
- PostgreSQL 14+ з `cube` extension - Node.js 18+ / Python 3.10+ для API - Redis для кешування сесій - Docker Compose для локальної розробкиЩо входить у розробку
- Документація: API spec (OpenAPI), архітектурна схема, інструкція з розгортання
- Доступи: App Store Connect, Google Play Console, Firebase
- Навчання: 2 години для адміністраторів, відеоінструкція для користувачів
- Підтримка: 1 місяць після релізу (баги та дрібні правки)
Зв'яжіться з нами для отримання консультації щодо вибору стеку та архітектури. Розрахуємо бюджет під ваш проект і покажемо, як нетворкінг-додаток окупиться за рахунок нових ділових контактів.