Розробка мобільного додатку для продуктового магазину (доставка продуктів)

Розробка мобільного додатку для доставки продуктів

Доставка продуктів — один із найбільш технічно складних сегментів у мобільній розробці. Великий каталог (тисячі позицій), управління залишками в реальному часі, замінювання товарів, збірка замовлення на складі, логістика останньої милі. Кожен із цих блоків — окремої системи. Завдання — зробити так, щоб вони працювали як одне ціле.

Каталог із тисячами позицій — це не просто список

Перша проблема, яка виникає при розробці доставки продуктів — продуктивність каталогу. 5000+ SKU, пошук, фільтри за категоріями, акціями, брендами. Наївна реалізація — завантажити все та фільтрувати локально — не працює.

Правильний підхід: серверна пагінація та фільтрація. Flutter + Flutter infinite_scroll_pagination: запитуємо 20 позицій, при прокруткою до кінця — наступні 20. Пошук — серверний, через PostgreSQL full-text search (tsvector + tsquery) або Elasticsearch для складних запитів з опечатками (нечіткий пошук через Levenshtein distance).

Кешування популярних категорій у Redis: домашня сторінка з акціями та бестселерами оновлюється раз на 5 хвилин, а не при кожному запиті.

Залишки в реальному часі. Товар закінчився на складі — він повинен зникнути з каталогу негайно, не через наступну синхронізацію. Оновлення залишків через WebSocket-подію або SSE (Server-Sent Events): клієнт підписаний на канал категорії, сервер відправляє зміни.

Збірка замовлення та замінювання

Після оформлення замовлення йде збирачу на склад. Додаток збирача — окремий Flutter-інтерфейс: список позицій, сканування штрих-коду для підтвердження, позначення «немає в наявності» з пропозицією заміни.

Заміни — чутливий момент. Збирач пропонує замінювання → клієнт отримує push і повинен підтвердити або відхилити. Тайм-аут 5 хвилин: якщо не відповів — застосовується автоматична заміна (аналог з тієї ж категорії) або позиція виключається з замовлення з перерахунком суми.

Цей потік вимагає: WebSocket між додатком збирача та клієнтським додатком, перерахунок суми замовлення на льоту, push з високим пріоритетом (FCM High Priority, priority: high у payload).

Слоти доставки та логістика

Клієнт вибирає слот: сьогодні з 18 до 20, завтра з 10 до 12. Доступні слоти — це серверна логіка: кількість активних кур'єрів × ємність слота − вже занятих замовлень. Не хардкод, а динамічний розрахунок.

Зони доставки: полігони в PostGIS. При введенні адреси перевіряємо, чи точка потрапляє в зону доставки (ST_Contains), і якщо так — показуємо доступні слоти для цієї зони.

Трекінг кур'єра — координати через WebSocket, маркер з анімацією на flutter_map. Розраховане час прибуття через Yandex Routes API з урахуванням затримок.

Програма лояльності та персоналізація

Накопичувальні бали — стандарт для доставки продуктів. Але ефективніше працює персоналізація: «Ви зазвичай замовляєте молоко раз на тиждень — він незабаром закінчиться». Це не ML-магія, це проста аналітика за історією замовлень: частота покупки товару × середній час між замовленнями = дата наступного передбачуваного замовлення. Push за день до цієї дати.

Автозаповнення кошика: «Повторити останнє замовлення» — один дотик, всі позиції в кошику, недоступні — виключені, решта — з актуальними цінами.

Типові помилки при розробці

Реалізувати кошик лише на клієнті (SharedPreferences). При авторизації з нового пристрою кошик втрачається. Кошик повинен жити на сервері, синхронізуватися з клієнтом.

Забути про повернення. Клієнт отримав пошкоджений товар — повинен бути потік у додатку: фото + опис → заявка на повернення → рішення протягом 24 годин → повернення через YooKassa API.

Стек технологій

Flutter 3.x + Bloc, Laravel 10 + WebSocket, PostgreSQL + PostGIS + Elasticsearch (для пошуку), Redis, FCM, YooKassa з підтримкою повернень, Yandex MapKit + Yandex Routes API.

Повний цикл розробки доставки продуктів з нуля — 28–40 тижнів залежно від обсягу інтеграцій та вимог масштабування.

Вартість розраховується індивідуально після аналізу вимог.