У засновника (назвемо його Марком) на столі лежали дві пропозиції. Один і той самий обсяг робіт, ті самі терміни, але одна з них була на 40 000 доларів дешевшою. Він уважно вивчив обидві, шукаючи підступ. У підсумку він так і не зміг пояснити цю різницю.
Різниця стала помітною через три місяці після початку розробки, коли система диспетчеризації не змогла обробити 40 одночасних замовлень без збоїв у черзі, а додаток для кур’єрів втрачав GPS-координати щоразу, коли водій заїжджав у підземний перехід.
Жодна з цих проблем не є унікальною, і команди, які раніше займалися розробкою додатків для доставки їжі, очікують їх. Команди, які ще не зіткнулися з ними, — за ваш рахунок.
Маючи 16-річний досвід надання послуг з розробки додатків для доставки на замовлення, ми не будемо вчитися за ваш рахунок. Ми знаємо, чого зазвичай не включає дешевша пропозиція, і розповімо про це в цьому посібнику з розробки додатків для доставки їжі.
Коротко
- У дешевших пропозиціях щодо додатків для доставки їжі зазвичай відсутня інфраструктура, яка виходить з ладу першою: інтелектуальне розподілення замовлень, офлайн-потоки кур’єрів, логіка розрахунку часу прибуття (ETA) та інтеграції.
- Перелік функцій може виглядати однаково у різних постачальників. Різниця стає помітною, коли через систему починають проходити реальні замовлення, кур'єри та ресторани.
- Диспетчерській службі потрібен механізм оцінки, оскільки при великих обсягах логіка «перший доступний кур’єр» не працює.
- «Мертві зони» — це частина повсякденної роботи з доставки, тому додатки для кур’єрів з самого початку потребують офлайн-режиму.
- Очікуваний час прибуття (ETA) має оновлюватися на основі реальних даних, таких як статус ресторану, час очікування кур’єра та умови маршруту.
- SaaS під власною торговою маркою спочатку здається дешевшим, але комісії за замовлення та обмеження постачальника накопичуються у міру зростання обсягів.
- Перш ніж підписувати договір, задайте постачальникам конкретні запитання щодо навантаження диспетчерської служби, офлайн-режиму, результатів пошуку та архітектурних рішень, спрямованих на економію коштів.
Чому розробка додатків для доставки їжі є складною
Обсяг ринку онлайн-доставки їжі наближається до 1,51 трлн доларів, тому не дивно, що багато команд пропонують розробку мобільних додатків для доставки їжі. Але лише деякі з них справді створювали такі додатки раніше і знають, у чому полягає складність.
Розподіл замовлень при великих обсягах
Коли під час 20-хвилинного вечірнього піку надходить 40 замовлень, система розподілу замовлень має призначити кожне з них кур’єру. При цьому вона має враховувати відстань, поточне навантаження, перекриття маршрутів та час на підготовку замовлення в ресторані. І все це — майже в режимі реального часу. Команда, яка раніше ніколи не працювала з логікою розподілу замовлень, реалізує це як просту чергу: наступне замовлення отримує перший доступний кур’єр. Це працює при 5 замовленнях на годину. При 50 — система дає збій.
Щоб реалізувати це правильно, нашій компанії з розробки логістичного програмного забезпечення потрібен механізм розподілу замовлень, який оцінює кожного доступного кур’єра залежно від того, наскільки близько він знаходиться, скільки активних замовлень у нього в роботі, як далеко місце отримання знаходиться від його поточного маршруту тощо. І передає замовлення тому, хто набрав найбільшу кількість балів.
Офлайн-режим додатка для кур'єрів
Уявіть собі таке. Кур'єр заходить у вестибюль будівлі, і сигнал зникає → додаток зависає посеред виконання завдання → на екрані клієнта й досі висвічується «скоро прибуде». І так буде протягом наступних 20 хвилин, оскільки кур'єр і сервер втратили зв'язок один з одним.
«Мертві зони», такі як паркінги та ліфтові шахти, є частиною щоденних маршрутів, і додаток, що залежить від постійного з’єднання, там не працюватиме.
Щоб цього уникнути, додатку потрібен локальний рівень стану. Кур’єр може приймати замовлення, оновлювати статуси та продовжувати рух навіть у режимі офлайн. Ці дії зберігаються на пристрої, а потім синхронізуються, щойно з’являється з’єднання. Якщо тим часом на сервері щось змінилося, додатку потрібні правила, щоб вирішити цю ситуацію без втрати даних або дублювання роботи.
Перерахунок часу прибуття (ETA) у реальному часі в разі затримок
Клієнт бачить час прибуття (ETA) 30 хвилин. Ресторану потрібно 22 хвилини на підготовку замість 10. Кур’єр чекає. Час прибуття, який бачить клієнт, тепер неточний на 12 хвилин, але додаток про це ще не знає, оскільки логіка розрахунку ETA була побудована на основі приблизного часу підготовки, а не фактичного.
Натомість додаток має оновлювати час доставки на основі реальних даних. Якщо ресторан ще готує замовлення, час прибуття змінюється. Якщо кур’єр чекає, цей час додається. Як тільки кур’єр починає рухатися, час прибуття перераховується на основі маршруту.
Щоб це працювало, система об’єднує три джерела інформації: статус ресторану, відстеження кур’єра та логіку розрахунку ETA. Серверний модуль перераховує час доставки щоразу, коли відбувається одна з цих змін, щоб клієнт бачив, що відбувається.
Рівень інтеграції POS та кухонних дисплеїв
Додаток для доставки їжі, який не підключається до існуючих систем ресторану, створює ручну роботу. Персонал вручну копіює деталі замовлення з платформи доставки в POS, тоді як на кухонних дисплеях замовлення на доставку не відображаються.
Кожна POS-система має власний формат API, метод аутентифікації та логіку оновлення даних. Деякі ресторани взагалі не використовують сучасні POS-системи. Ви не зможете правильно оцінити обсяг цих інтеграцій, доки не дізнаєтеся, до яких саме систем має підключатися ваш додаток. І це обговорення має відбутися на етапі аналізу потреб. Команди з досвідом у цій галузі це знають.
Диспетчеризація та прогнозування доставки на основі штучного інтелекту
Як ми вже згадували раніше, диспетчеризація на основі правил у 2026 році не працює. Платформи, що встановлюють сучасні стандарти, замінили цю логіку ще кілька років тому. Наприклад, DoorDash. Це технологічна компанія, яка з’єднує клієнтів із ресторанами, міні-маркетами та роздрібними магазинами для доставки на замовлення. Вони створили DeepRed — механізм розподілу замовлень на основі машинного навчання, який підбирає до кожного замовлення найбільш підходящого «Dasher» (так у DoorDash називають незалежних кур’єрів) з урахуванням умов у реальному часі.
Це працює так: спочатку система формує список потенційних кандидатів для виконання замовлення, скануючи доступних «Dasher» поблизу та існуючі замовлення. Потім шар машинного навчання прогнозує час готовності замовлення, час у дорозі та ймовірність того, що «Dasher» прийме пропозицію. Нарешті, модель оптимізації оцінює та ранжує всіх кандидатів, приймає рішення щодо групування замовлень і визначає, чи відправляти кур’єра негайно, чи чекати на кращого «Dasher».
Це не обмежується лише відправленням замовлення. Системи штучного інтелекту тепер попереджають про ймовірні затримки на кухні ще до того, як кур’єр почне чекати, перерозподіляють кур’єрів напередодні пікових навантажень та автоматично вилучають позиції з меню, коли запаси сигналізують про їхнє майже повне вичерпання.
Для нової платформи це не потрібно створювати з першого дня. Але архітектуру даних, яка це уможливлює, слід проектувати з урахуванням цього з самого початку.
З правильним партнером ви уникнете складних моментів і не будете платити за те, щоб навчитися їх на власних помилках. Давайте подивимося, де саме можуть виникнути ці складні моменти.
Функції, необхідні для платформи доставки їжі на замовлення у 2026 році, та чому вони важливі
Коли команда працює над проектом розробки додатка для доставки їжі на замовлення, вона створює три додатки, що взаємодіють між собою: додаток для клієнтів для оформлення замовлень, додаток для ресторанів для управління кухнею та додаток для кур’єрів для виконання доставок. Кожен із них може дати збій по-різному, якщо його розроблено без досвіду у сфері доставки.
Додаток для клієнтів
Додаток для клієнтів — це та частина, яку ми всі знаємо і любимо. Ви переглядаєте меню, вибираєте те, що хочете, оплачуєте, а потім кожні 30 секунд відстежуєте своє замовлення, поки воно не прибуде. Ось і весь основний алгоритм. Звучить просто, правда? Але кожен крок приховує свої сюрпризи.
Перегляд меню та пошук
Клієнти переглядають ресторани за типом кухні, рейтингом або часом доставки, а потім фільтрують результати за дієтичними вимогами, ціновим діапазоном або акційними пропозиціями.
Коли меню не оновлюється на основі даних у реальному часі, клієнти бачать позиції, які вже розпродані. Замовлення проходить, а потім скасовується, і більшість клієнтів більше не намагаються замовити.
Оформлення замовлення та оплата
Під час оформлення замовлення ви вказуєте свою адресу, обираєте спосіб оплати, можливо, додаєте чайові або промокод, і підтверджуєте замовлення. Система має підтримувати різні способи оплати, такі як картка, електронний гаманець, оплата при отриманні, а також обробляти невдалі транзакції без втрати вмісту кошика.
Якщо оплата не синхронізована зі створенням замовлення, система може списати кошти з рахунку користувача, але не створити замовлення або створити його без підтвердження оплати.
Відстеження замовлення в режимі реального часу
Після оформлення замовлення клієнт бачить інтерактивну карту з місцезнаходженням кур’єра та постійно оновлюваним часом прибуття. Вона враховує час підготовки, час очікування кур’єра та поточні умови на маршруті.
Без належної інтеграції системи відстеження оновлення в режимі реального часу не працюють, і клієнти не мають можливості дізнатися, чи щось пішло не так.
Повторне замовлення
Повторне замовлення має здійснюватися одним натисканням. Клієнту не потрібно заново формувати кошик або вводити свою адресу.
Якщо повторне замовлення вимагає більше, ніж одного натискання, більшість користувачів не скористаються цією функцією. Це означає менше повторних замовлень і втрату доходу.
Оцінки та відгуки
Після кожної доставки клієнт отримує запит оцінити досвід: якість їжі, упаковку, розмір порції, швидкість доставки та поведінку кур’єра.
Якщо оцінки не пов’язані з конкретними кур’єрами, ви не знатимете, що половина скарг на запізнення з доставкою припадає на двох кур’єрів.
Панель ресторану
Панель ресторану — це та частина, яку клієнт ніколи не бачить, але відчуває з кожним замовленням. Якщо все налаштувати неправильно, це призведе до помилок у замовленнях, затримок із видачею та розчарованих кур’єрів, які чекають біля стійки.
Управління замовленнями
Кожне вхідне замовлення з’являється на екрані ресторану в режимі реального часу з можливістю прийняти, відхилити або позначити як затримку. Коли кухня приймає замовлення, запускається таймер приготування, який відстежує хід роботи порівняно з прогнозом, надісланим диспетчерській службі, та очікуваним часом прибуття (ETA) для клієнта. Якщо кухня відстає від графіка, персонал може оновити час приготування в активному замовленні, і ця зміна автоматично передається до диспетчерської служби кур’єрів та відображається в ETA, що бачить клієнт.
Якщо статус замовлення та час приготування не синхронізуються в режимі реального часу, диспетчерська служба продовжує використовувати застарілі оцінки. Кур’єри приїжджають занадто рано або занадто пізно, і затримка стає помітною лише тоді, коли замовлення вже відхилилося від графіка.
Управління меню та наявністю продуктів
Ресторан контролює все, що з’являється на платформі, включаючи назви позицій, описи, фотографії, ціни, варіанти порцій та модифікатори. Наявність можна вмикати чи вимикати для кожної позиції в режимі реального часу, тож коли щось закінчується посеред обслуговування, воно одразу зникає з додатка для клієнтів.
Коли зміни в наявності не синхронізуються миттєво, клієнти замовляють позиції, які кухня перестала готувати ще годину тому. Замовлення скасовується після оплати, а ресторан отримує скаргу.
Інтеграція з кухонним дисплеєм
Вхідні замовлення надходять безпосередньо на екран у кухні. На дисплеї відображаються деталі замовлення, час виконання та статус. Для ресторанів, які вже використовують POS-систему, інтеграція працює в обох напрямках: надходять замовлення, а також надходять оновлення запасів.
Визначте обсяг інтеграції з кухонним дисплеєм на ранньому етапі. Інакше це може знову стати обов’язковою вимогою на другому місяці після затвердження архітектури. Це призведе до незапланованого розширення обсягу робіт, додаткових витрат та переробки.
Звіти про продажі
Ресторан бачить щоденний обсяг замовлень, виручку за позиціями та часовими проміжками, динаміку пікових годин, середню вартість замовлення та рівень скасування замовлень.
Якщо звітність додається вже після запуску, цифри можуть не збігатися, що породжує сумніви щодо надійності даних платформи.
Додаток для кур'єрів
Додаток для кур'єрів повинен працювати навіть за умов слабкого сигналу, коли кур'єр керує велосипедом однією рукою, а екран телефону потрапляє під прямі сонячні промені. Він має бути швидким і функціональним навіть за відсутності мережі.
Призначення та прийняття замовлень
Коли надходить нове замовлення, кур'єр бачить місце забору, назву ресторану, приблизний час підготовки, відстань та суму виплати. Він приймає або відхиляє замовлення протягом встановленого проміжку часу. Якщо відповіді немає, система диспетчеризації автоматично перепризначає замовлення іншому кур'єру та переходить до наступного.
Проста черга замість алгоритму ранжування за результатами призводить до неефективного розподілу замовлень серед кур’єрів. Замовлення надходять до водіїв, які не знаходяться поблизу або вже перевантажені роботою.
Навігація
Додаток прокладає маршрут кур’єра від його поточного місцезнаходження до ресторану, а потім до адреси доставки. Маршрут оновлюється в режимі реального часу та враховує час очікування в ресторані, тому очікуваний час прибуття (ETA) є точним для клієнта.
Навігація, яка ігнорує час очікування на забирання замовлення, порушує точність прогнозованого часу прибуття (ETA) в той момент, коли кур’єр приїжджає, а їжа ще не готова. Додаток не відображає жодних коригувань, доки рух не відновиться. До того часу доставка вже запізнюється.
Офлайн-режим
Додаток продовжує працювати, коли зникає сигнал. Нові завдання, оновлення статусу та підтвердження доставки зберігаються локально на пристрої та синхронізуються, щойно з’являється з’єднання.
Система, що залежить від постійного з’єднання, перестає працювати в зонах зі слабким сигналом.
Заробіток та історія
Кожна виконана доставка додається до поточного розрахунку базової оплати, чайових та бонусів. Сума оновлюється в режимі реального часу, і кур’єр може переглянути повну історію за день або тиждень без звернення до служби підтримки.
Затримки в оновленні даних про заробіток викликають сумніви. Кур'єри не знають, чи була доставка врахована, тому звертаються до служби підтримки. І з розширенням автопарку кількість таких запитів зростає.
Кожна з цих функцій залежить від того, як система спроектована та побудована. Ось підхід, якого дотримується Stfalcon.
Як виглядає розробка онлайн-додатків для доставки їжі від Stfalcon
Ми поділяємо розробку на п’ять етапів, кожен з яких має чіткий результат.
Аналіз
Наша команда розпочинає розробку додатка для онлайн-доставки їжі з ретельного аналізу ваших робочих процесів доставки, наявних технологій та бізнес-цілей. На основі цього ми визначаємо технологічний план, який визначає всі подальші кроки.
Під час аналізу ми часто виявляємо вимоги, яких не було у початковому брифі, але їх своєчасне врахування дозволяє уникнути витрат на доопрацювання в майбутньому. Наприклад, під час проєкту SMILEFOOD на етапі аналізу виявилося, що значна частка користувачів робить друге замовлення протягом 20 хвилин після першого. Це спостереження безпосередньо вплинуло на створення процесу повторного замовлення одним натисканням, який зараз є однією з функцій додатка з найвищим рівнем залученості.
Результати → специфікація функцій, діаграми користувацьких потоків, журнал рішень щодо технічної архітектури, реєстр ризиків та графік розробки, прив’язаний до конкретних етапів.
Дизайн
Ми беремо потоки, визначені на етапі дослідження, і перетворюємо їх на конкретні шляхи користувачів. Для кожної ролі, наприклад клієнта, кур’єра чи оператора, ми покроково простежуємо їхні дії. Потім ми створюємо прототипи цих потоків і тестуємо їх на ранніх етапах. Якщо кур’єру потрібно зробити два додаткові натискання під час руху, ми виправляємо це одразу.
Одночасно ми визначаємо, що відповідає за диспетчеризацію, як відбувається обмін даними між сервісами та де розташовані інтеграції. До моменту початку розробки логіка продукту та структура системи є чіткими, що дозволяє приступити до створення.
Результат → клікабельний прототип, тестування зручності користування, архітектура рішення.
Розробка
Маючи готову архітектуру, команда приступає до розробки. Команди бекенду, фронтенду, мобільних додатків та DevOps працюють над однією структурою, тому рішення залишаються послідовними у міру розширення системи.
Ми не починаємо з нуля при створенні інфраструктури доставки. Основні компоненти, такі як логіка розподілу замовлень, відстеження в режимі реального часу, верифікація користувачів та оплата, вже розроблені та використовуються в діючих продуктах. Ми повторно використовуємо та адаптуємо їх до ваших потреб, що дозволяє заощадити приблизно 30% порівняно з розробкою всього з нуля.
Наприклад, під час роботи над Balabing ми використовували «Чисту архітектуру» зі спільними модулями домену та даних для клієнтських і постачальницьких додатків. Це дозволило нам повторно використовувати одну й ту саму бізнес-логіку, що прискорило розробку та спростило впровадження майбутніх змін в обох додатках.
Результат → індивідуальний додаток для доставки на замовлення з адаптованим набором технологій та всіма необхідними інтеграціями із сторонніми сервісами.
Тестування
При розробці додатків для замовлення та доставки їжі тестування виходить за межі стандартного контролю якості. Воно включає сценарії, які багато команд часто пропускають, такі як офлайн-режим для кур’єрів, обробка дубльованих зворотних викликів щодо оплати та забезпечення точності очікуваного часу прибуття (ETA), коли кухні затримуються. Контроль якості Stfalcon охоплює ці аспекти в рамках стандартних критеріїв приймання.
Додаток також проходить перевірки безпеки та оптимізацію продуктивності, щоб у виробничому середовищі не виникали крайні випадки та вразливості.
Результат → Звіт з контролю якості, результати тестів на навантаження та продуктивність, аудит безпеки та збірка, готова до релізу.
Випуск та період після запуску
Система запускається в експлуатацію та починає обробляти реальні замовлення, кур’єрів та діяльність ресторанів. На цьому етапі основні робочі процеси вже готові, тому основна увага переноситься на те, як працює система.
Команда займається розміщенням у магазинах додатків, остаточним налаштуванням середовища та координацією релізу. Ми також моніторимо продуктивність, стабілізуємо систему та забезпечуємо її надійність у міру початку реального використання. Цей етап є контрольованим розгортанням, тому наша команда продовжує брати в ньому участь.
Саме за описаний вище етап ви платите. Але це не єдиний варіант отримання додатка для доставки їжі. Ось скільки коштують альтернативні варіанти та коли самостійна розробка перестає бути найдорожчим вибором.
Скільки коштує розробка додатка для доставки їжі на замовлення (і коли індивідуальна розробка виграє у SaaS)
Платформи «white-label» на перший погляд здаються доступними. Візьмемо одну з них як приклад. YelowXpress пропонує тарифний план «Growth» від 99 доларів на місяць. Ця цифра справжня. Однак у ній не вказано комісію в розмірі 1,3% за кожне замовлення, одноразову плату за налаштування у розмірі 2 499 доларів та 0,11 долара за кожне замовлення понад 3 000 на місяць.
DoorDash повідомляє, що середня вартість замовлення на їхній платформі становить менше 40 доларів, тому ми використовуємо цю цифру як базу для розрахунків. При такій сумі комісія у розмірі 1,3 % додає 0,52 долара до кожного обробленого замовлення.
Ось як це виглядає у випадку з YelowXpress на основі цін, вказаних на їхньому веб-сайті:
| При 5 000 замовлень на місяць | При 20 000 замовлень на місяць |
|---|---|
| Абонемент: 99 доларів | Абонемент: 99 доларів |
| У комплекті: 3 000 замовлень | У комплекті: 3 000 замовлень |
| Перевищення: 2 000 × 0,11 дол. = 220 дол. | Перевищення: 17 000 × 0,11 $ = 1 870 $ |
| Комісія за замовлення: 5 000 × 0,52 $ = 2 600 $ | Комісія за замовлення: 20 000 × 0,52 дол. = 10 400 дол. |
| Місячна загальна сума: 99 $ + 220 $ + 2 600 $ = 2 919 $ | Місячна загальна сума: 99 $ + 1 870 $ + 10 400 $ = 12 369 $ |
| 1-й рік: 2 919 $ × 12 + 2 499 $ (вступний внесок, сплачується лише один раз) = 37 527 $ | 1-й рік: 12 369 $ × 12 + 2 499 $ (вступний внесок, сплачується лише один раз) = 150 927 $ |
| Накопичена сума за 3-й рік: ~107 583 дол. | Накопичення за 3-й рік: ~447 783 дол. |
На практиці компанії не обирають навмисно тарифний план на 3 000 замовлень, щоб потім платити за перевищення ліміту. Вони обирають тарифний план, виходячи з очікуваного обсягу. Але зростання, сезонність або піки попиту можуть змусити їх перевищити цей ліміт. Навіть у такому випадку перевищення ліміту не є основним фактором витрат. Ним є комісія за кожне замовлення. І вона зростає з кожним замовленням.
Якщо ви оберете розробку індивідуального додатка для доставки їжі разом із Stfalcon, ви заплатите приблизно 80 000–120 000 доларів за розробку, плюс ~15 % від вартості проєкту щорічно на технічне обслуговування. Тепер порівняємо це з SaaS-платформою за три роки.
| 1-й рік | 2-й рік | 3-й рік (сумарно) | |
|---|---|---|---|
| YelowXpress (5 тис. замовлень на місяць) | ~38 000 доларів | ~35 000 дол. | ~108 000 |
| YelowXpress (20 тис. замовлень на місяць) | ~151 000 дол. | ~148 000 доларів | ~448 000 |
| Індивідуальна розробка (Stfalcon) | 80 000–120 000 доларів | 12 000–18 000 | 116 000–174 000 |
Є також те, чого цифри не відображають. З платформою «white-label» ви не можете змінювати логіку диспетчеризації, додавати власний процес верифікації кур'єрів або інтегруватися з POS-системою, яку постачальник не підтримує. Коли вам потрібні такі зміни (а вони потрібні більшості операторів, що розвиваються), залишається лише чекати на дорожню карту постачальника або заплатити за повну міграцію.
Незважаючи на цифри, найпростіший спосіб зрозуміти, що дає індивідуальна розробка, — це подивитися на те, що вже створено.
Деякі з наших проєктів з розробки мобільних додатків для доставки їжі
Ось кілька проектів з розробки додатків для доставки їжі на замовлення, над якими ми працювали; кожен із них вирішував різні завдання.
SMILEFOOD
SMILEFOOD — це онлайн-сервіс замовлення їжі, який зіткнувся з типовою проблемою: існуючий мобільний додаток гальмував розвиток компанії. Створений на базі Ionic як копія веб-сайту, він ставав дедалі нестабільнішим, а його обслуговування з кожним оновленням ускладнювалося.
Ми розпочали з аналізу. Команда проаналізувала потік замовлень, склала користувацькі історії та оцінила два варіанти розробки: окремі нативні додатки для Android та iOS або єдиний додаток на базі Flutter. Далі основна увага перейшла на дизайн. Ми визначили, як додаток працюватиме на практиці, включаючи відстеження кур’єрів, індивідуальні замовлення, інтеграцію з існуючою базою даних та план міграції на новий технологічний стек.
У результаті SMILEFOOD отримав готовий дизайн додатка з вирішеними заздалегідь ключовими крайніми випадками, набір інтерфейсних елементів для розробки та план підключення нової системи й міграції існуючої бази користувачів.
Balabing
Balabing почався з простого спостереження: фургони з їжею приваблюють натовпи, а ці натовпи перетворюються на черги. Оформлення замовлення займає час, і очікування стає частиною досвіду. Ідея полягала в тому, щоб усунути це очікування.
Щоб це запрацювало, Balabing звернувся до Stfalcon. Нам потрібно було створити платформу, яка б дозволяла клієнтам робити замовлення заздалегідь у кілька натискань, при цьому синхронізуючи замовлення, меню та час отримання з боку оператора.
Система була побудована у вигляді двох взаємопов’язаних частин. Мобільні додатки для iOS та Android відповідали за оформлення замовлень та їх відстеження. Веб-панель адміністратора надавала команді контроль над меню, замовленнями та повсякденними операціями.
За цим стояли оновлення в режимі реального часу та відстеження місцезнаходження, що забезпечували синхронізацію всіх даних. Перша версія була запущена як MVP і вже виправдала очікування клієнта. Це дало їм робочий продукт на ринку та основу для подальшого розширення у міру зростання платформи.
Глобальна платформа доставки їжі
Глобальна платформа, що обробляє понад 500 мільйонів замовлень на рік, зіткнулася з проблемами у комунікації між ресторанами та їхніми постачальниками продуктів. Ресторани керували замовленнями постачальників за допомогою електронної пошти та електронних таблиць, тоді як постачальники не мали уявлення про те, що саме потрібно.
Ми побудували систему на основі інструментів, якими вони вже користувалися. Ми об’єднали чат, каталоги товарів та створення замовлень в один робочий процес. Щоб швидше випустити мінімально життєздатний продукт (MVP), ми використали готові сервіси для чату (Stream) та каталогу (Shopify), інтегрувавши їх з існуючими каналами постачальників.
У результаті Stfalcon розробив модуль управління замовленнями, який з’єднав обидві сторони в рамках існуючої інфраструктури. Сотні ресторанів почали користуватися ним ще до повного завершення розробки.
Якщо у портфоліо постачальника немає подібних проєктів з доставки їжі, краще перевірити його компетенцію. Деякі команди мають досвід, але не демонструють його. Інші ж не мають його взагалі.
Stfalcon відповідає на всі п’ять питань, наводячи конкретні проєкти та архітектурні рішення, про які ви можете запитати. Логіка диспетчеризації, інфраструктура кур’єрської служби та моделі інтеграції POS-систем були створені та вдосконалені протягом 16 років реалізації логістичних проєктів. Як компанія з розробки програмного забезпечення длятранспорту та логістики, ми знаємо, де ці системи дають збій, і як їх будувати, щоб цього не сталося.
Готові створити додаток для доставки їжі? Почніть з цифр
Під час 30-хвилинної розмови з нами ми обговоримо потенційні ризики, реалістичний графік та діапазон витрат, який ви зможете представити зацікавленим сторонам.
Аліна
Менеджерка з роботи з клієнтами
Кожна агенція скаже вам, що раніше вже реалізовувала комплексні проекти з розробки додатків для доставки їжі. Ці запитання допоможуть з’ясувати, наскільки глибоко вони в цьому розбираються.
Питання, які слід задати команді розробників перед тим, як найняти її
Як ви справляєтеся з розподілом замовлень під час пікового навантаження? Який алгоритм ви використовуєте і який максимальний обсяг замовлень ви тестували?
Конкретна відповідь має містити назву типу алгоритму, приклад реального проєкту та цифру обсягу. Нечітка відповідь означає, що вони не створювали такого рішення у великих масштабах.
Як ви реалізуєте офлайн-режим у додатку для кур’єрів?
Якщо відповідь звучить так: «Ми синхронізуємо дані, коли з’явиться з’єднання», запитайте, що відбувається зі станом сервера, поки кур’єр перебуває в офлайн-режимі, і чи вирішуються конфлікти автоматично. Загальні відповіді на це питання згодом виявляються як помилки в робочій версії.
Що дає ваша фаза дослідження?
Список функцій не є результатом фази виявлення. Результатами є карти шляху користувача, перевірені припущення, рекомендації щодо архітектури та позначки про ризики в обсязі робіт. Якщо фаза виявлення — це тижнева нарада щодо обсягу робіт, ризики виявляються під час розробки за ставками розробників.
Як ліцензуються та кому належать ваші модулі?
Готові модулі прискорюють реалізацію. Але деякі постачальники зберігають за собою право власності на ці модулі, а це означає, що ви отримуєте ліцензію на код, а не володієте ним. Контракт повинен надавати вам повне право власності на все, що розгорнуто у вашій кодовій базі.
Чи можете ви розповісти про архітектурне рішення, яке заощадило клієнту кошти?
Досвідчені команди мають такі історії: готові модулі, певний дизайн API, модель даних, завдяки якій додавання функцій обійшлося дешевше, ніж повна перебудова. Якщо вони не можуть назвати хоча б один приклад, означає, що довгострокові витрати не були частиною їхнього мислення.
