Більшість компаній починають розробку додатка для доставки, виходячи з одного й того самого припущення: нам потрібен мобільний додаток із GPS-відстеженням та функцією оплати.
Це правильно, але не повністю. Це охоплює навіть не половину того, що потрібно додаткам для доставки, тому проєкти зупиняються, бюджети перевищуються, а додатки виходять з ладу під навантаженням.
Насправді командам потрібен не просто додаток, а тристороння платформа, яка координує взаємодію клієнтів, постачальників та кур’єрів у режимі реального часу. Інтерфейс — це лише невелика частина системи, тоді як решта (компоненти, маршрутизація, платежі, синхронізація в режимі реального часу, адміністративна інфраструктура) не враховуються.
У нашій компанії з розробки програмного забезпечення для транспорту та логістики ми створювали логістичні додатки та додатки для доставки на замовлення для таких гігантів, як Ecolines та Nova Post — провідної служби експрес-доставки в Україні, — тому ми знаємо, що для цього потрібно.
У цьому посібнику ми розберемо найпоширеніші (і найдорожчі) помилки у розробці додатків для доставки на замовлення. Ми покажемо, як створити додаток для доставки, та пояснимо, як підходити до ключових рішень, щоб уникнути перевитрат бюджету та прострочення термінів.
Коротко
- Більшість компаній, які планують створити додаток для доставки, недооцінюють те, що насправді створюють: це не просто додаток, а тристороння торговельна платформа
- Три найдорожчі помилки: відстеження в режимі реального часу — це просто GPS; оплата працює так само, як у звичайному інтернет-магазині; ви розробляєте лише один додаток
- SaaS виграє в перший рік за швидкістю та вартістю. Індивідуальна розробка виграє на 2–3-му році, коли накопичуються комісії та обхідні рішення
- Розробка становить 30–40 % від загальних витрат за два роки. Решта — це інфраструктура, API, тестування, технічне обслуговування та дотримання нормативних вимог
- Найбільш недооціненою статтею витрат є наймання команди універсальних фахівців для розробки логіки домену доставки в межах вашого бюджету
- Правильний партнер з розробки, особливо у сфері мобільних додатків для доставки, вже створював подібні системи раніше й може підтвердити це конкретними прикладами
Ви думаєте, що просто створюєте додаток для доставки, тоді як насправді це тристоронній ринок
У 2013 році Кевін Гіббон запустив Shyp з ідеєю, яка здавалася безпрограшною. Зробіть фото того, що потрібно відправити. Кур'єр приїжджає до ваших дверей, упаковує товар і відправляє його через FedEx або UPS — і все це за 5 доларів. Shyp залучив 62,1 млн доларів фінансування, а на піку своєї популярності його оцінювали в 250 млн доларів. Ззовні це виглядало як історія успіху додатку для доставки, що тільки набирала обертів.
Однак 27 березня 2018 року Гіббон оголосив про закриття Shyp. «Я підходив до всього як інженер, — зізнався він. — Моєю помилкою було прагнення зростання за будь-яку ціну».
Shyp створив чудовий, улюблений користувачами продукт, водночас систематично недооцінюючи, чим насправді є розробка додатків для доставки. Сам Гіббон описував Shyp як «дуже складний сервіс» зі складами в кожному місті, відданими співробітниками, індивідуальною упаковкою та логікою вибору перевізника, проте компанія продовжувала презентувати його світу як простий і дешевий додаток.
Саме цей розрив між тим, як виглядав додаток, і тим, що насправді було потрібно для його функціонування, став фатальним недоліком. Вони неправильно зрозуміли, що саме створювали.
Це помилка, яка постійно повторюється у розробці додатків для доставки на замовлення: початок роботи над проєктом із неправильною ментальною моделлю того, що створюється.
Коли компанія вирішує створити додаток для доставки, зазвичай припускається, що додаток для доставки = додаток із GPS-відстеженням + процесом оплати. Насправді ж вони створюють тристоронній ринок, що з’єднує клієнтів, продавців та кур’єрів, кожен із яких має власний додаток, логіку та режими відмови.
В основі цього лежать численні системи:
- Система логістики в режимі реального часу
- Механізм оплати та звірки
- Адміністративна панель
- Аналітичний рівень
Додаток, який бачать і яким користуються користувачі, становить приблизно 10% системи. Решта — це інфраструктура, логіка координації та операційна складність, з якими більшість команд розробників раніше не стикалися.
Компанії, які успішно справляються з цим, мають не просто кращих розробників. Вони починають з розуміння того, у що насправді вплутуються.
У Stfalcon, маючи 16-річний досвід надання послуг з розробки додатків для доставки на замовлення, ми часто бачимо продукти, які були створені неправильно. Тож давайте розвінчаємо 3 поширені міфи, які зазвичай призводять до невдач після запуску продукту.
3 міфи про розробку додатків для доставки. Чому ці додатки зазнають невдачі в експлуатації
Більшість проєктів додатків для доставки зазнають невдачі через шість місяців після запуску, коли реальний обсяг замовлень навантажує систему, побудовану на оптимістичних припущеннях. Ось три припущення, які завдають найбільшої шкоди.
Міф № 1: Відстеження в режимі реального часу — це лише позначка GPS на карті
Це та функція, яку кожен клієнт просить у першу чергу. Вони уявляють собі крапку, що рухається на екрані. Але за цією крапкою ховається розподілена система, яка має залишатися синхронізованою щонайменше у трьох інтерфейсах одночасно: у додатку клієнта, у додатку кур'єра та в адміністративній панелі диспетчера.
Клієнт бачить: «Кур’єр за 5 хвилин». Додаток кур’єра щойно втратив з’єднання в паркінгу. Адміністративна панель все ще показує замовлення як «у дорозі». Хто отримає сповіщення? Чи перераховується передбачуваний час прибуття? Чи стан замовлення «заморожується» чи «відкочується»? Без чіткої логіки резервного варіанту для кожного з цих сценаріїв нічого не відбуватиметься належним чином.
Коли Stfalcon розробляв додаток для логістичного обміну посилками, GPS-модуль був лише відправною точкою. Складнішою проблемою було відображення маршрутів із кількома зупинками та кількістю доступних посилок на кожній з них, управління місткістю транспортних засобів у реальному часі в міру того, як водії приймали або відхиляли посилки, а також сповіщення водіїв про нові посилки, що з’являлися на їхньому маршруті під час поїздки. Усе це має працювати навіть за умови переривчастого з’єднання, оскільки водії постійно перебувають у русі.
Переконайтеся, що команда, з якою ви працюєте над створенням додатка для доставки, вже реалізувала подібні рішення.
Міф № 2: Оплата працює так само, як і в електронній комерції
У стандартному інтернет-магазині невдалий платіж — це лише незручність. Користувач бачить повідомлення про помилку, пробує іншу картку або повертається завтра.
У додатку для доставки на момент невдалого платежу щонайменше дві інші сторони вже перебувають у процесі виконання дії. Збій платіжного шлюзу означає розгублені кур’єри, суперечки з постачальниками, запити клієнтів на повернення коштів та команду підтримки, яка вирішуватиме наслідки протягом наступних 48 годин.
Додатки для доставки потребують платіжної інфраструктури, яка з самого початку була розроблена для узгодження дій між кількома сторонами:
- Логіка роздільного розрахунку
- Обробка повернень коштів за часткові доставки
- Резервний шлюз, що активується автоматично
- Логіка скасування замовлення
Це інша інженерна проблема, ніж у випадку з платежами в електронній комерції.
Причина невдач тут часто полягає у правильній інтеграції неправильної ментальної моделі. Команда створює те, що знає: це працює під час тестування, але виходить з ладу в виробничому середовищі.
Міф № 3: Ви розробляєте лише один додаток
Це найдорожче помилкове уявлення, оскільки воно з самого початку впливає на кожну оцінку, графік і рішення щодо ресурсів.
Платформа доставки — це не один додаток. Ми говоримо про щонайменше чотири окремі продукти, які, як виявляється, мають спільний бекенд: додаток для клієнтів, додаток для постачальників або ресторанів, додаток для кур’єрів та адміністративна панель. Кожен із них має свій тип користувачів, логіку взаємодії та рівень сповіщень.
Коли Stfalcon співпрацював із SmileFood над редизайном, існуючий додаток зависав або давав збій під час кожного оновлення. Основна проблема полягала в тому, що продукт було створено як єдиний додаток без цілісної моделі того, як різні ролі будуть синхронізуватися в умовах масштабування.
Ми провели етап аналізу ще до початку будь-яких робіт з проектування чи розробки та проаналізували шлях двох різних типів користувачів. Ми з’ясували, що повторне замовлення, зроблене протягом 20 хвилин після доставки, було одним із найцінніших моментів у життєвому циклі клієнта.
Це відкриття дозволило реструктурувати як архітектуру UX, так і логіку сповіщень. Це не той вид висновку, на який звернула б увагу команда загального профілю, не знайома з особливостями поведінки користувачів у сфері доставки.
Саме тому ми завжди рекомендуємо починати з етапу дослідження та пам’ятати, що у сфері доставки на замовлення це набагато більше, ніж просто додаток для користувачів.
Плануєте модернізувати свій додаток для доставки на замовлення або створити його з нуля?
Запишіться на дзвінок, і ми обговоримо ваші потреби
Аліна
Менеджерка по роботі з клієнтами
Наступне ключове питання, яке потрібно визначити, — це вічна дилема: SaaS чи індивідуальна розробка?
SaaS чи індивідуальна розробка: як створити додаток для доставки, який виправдає вкладені кошти
Обговорення того, як створити додаток для доставки, природно призводить до питання: чи варто розробляти індивідуальне рішення, чи краще обрати SaaS-платформу?
Це правильне питання. Але більшість людей формулюють його неправильно.
Платформи SaaS побудовані на основі власної логіки, власної моделі даних та власних припущень щодо маршрутизації. Ви можете працювати в рамках цієї логіки або створити власну. Чого ви не можете зробити (не заплативши за це чимало) — це почати з SaaS, а потім налаштовувати його, доки він не почне працювати як індивідуальна розробка.
Такий шлях призводить до найгіршого з обох варіантів: постійні платежі за SaaS, додаткові витрати на індивідуальну розробку та архітектура, якою повністю не володіє ані платформа, ані ваша власна команда.
Ось як з часом проявляється компроміс між SaaS та індивідуальним розробленням:
| SaaS | Індивідуальна розробка | |
|---|---|---|
| 1-й рік | Швидше та дешевше запустити | Повільніше, вищі початкові інвестиції |
| 2–3 рік | Накопичення комісій | Загальна вартість володіння знижується |
| Диференціація | Обмежена правилами платформи | Необмежена |
| Право власності на дані | Платформа зберігає дані | Повністю належать вам |
| Максимальний обсяг | Вбудований | Ви самі визначаєте |
Але бувають випадки, коли SaaS може бути для вас кращим варіантом, ніж індивідуальне рішення.
Коли SaaS є доцільним
- Ви перевіряєте попит на ринку, перш ніж вкладати капітал
- Ваші операції з доставки є стандартними
- Ваші обсяги ще настільки невеликі, що комісія за транзакцію все ще дешевша, ніж вартість індивідуальної інфраструктури
Коли індивідуальне рішення виграє
- Ваша бізнес-модель залежить від операційних відмінностей (динамічне ціноутворення, власні маршрути, індивідуальні системи мотивації кур’єрів)
- Ви працюєте на кількох ринках або у кількох галузях, де в кожній діє власна логіка доставки
- Комісії за SaaS стали значною часткою доходу
- Вам потрібно володіти власними даними для побудови прогнозів
Одне варто зазначити відразу: індивідуальний підхід не означає початок з нуля. Проєкти доставки від Stfalcon реалізуються швидше, ніж типові проєкти «з нуля», оскільки основні компоненти, такі як процеси оформлення замовлень, логіка маршрутизації, відстеження в режимі реального часу та звірка платежів, вже розроблені.
І це, звісно, знижує витрати на розробку.
Скільки насправді коштує створення додатка для доставки на замовлення
Як тільки вирішено питання «SaaS чи індивідуальна розробка», засновникам потрібна конкретна цифра. І саме тут більшість агентств роблять своїм клієнтам ведмежу послугу, називаючи або оманливо низьку суму, щоб отримати замовлення, або наводячи настільки широкий діапазон, що він стає марним.
Замість конкретної цифри корисніше розглянути структуру витрат. Розробка зазвичай становить 30–40% від загальної вартості платформи доставки протягом перших двох років. Решта витрат розподіляється приблизно так:
- Інфраструктура та хостинг: вартість прямо пропорційна обсягу замовлень; це не фіксовані витрати
- Сторонні API: Google Maps Platform, платіжні шлюзи та сервіси push-повідомлень оплачуються за фактичне використання; при масштабуванні витрати на них швидко зростають
- Контроль якості, тестування продуктивності, навантажувальні випробування та тестування безпеки: часто вважаються необов’язковими, доки не стають нагально необхідними
- Технічне обслуговування після запуску: зазвичай становить 15–25 % від початкового бюджету на розробку щорічно
- Публікація в магазинах додатків та постійне дотримання вимог: невеликі, але реальні витрати, про які легко забути під час початкових оцінок.
На тлі цієї структури ось як інвестиції в розробку співвідносяться з обсягом робіт:
| Витрати на додаток для доставки на замовлення | ||
|---|---|---|
| Базовий MVP | Версія середнього рівня | Повнофункціональна платформа |
|
|
|
| 20 000–50 000 доларів | 50 000–150 000 | 150 000–400 000+ доларів |
Приховані витрати, які майже ніхто не враховує на початку, — це оплата послуг команди універсальних фахівців, які мають розібратися в логіці сфери доставки, виходячи з вашого бюджету. Експертні знання в цій галузі — це пряме зниження витрат. Отже, перейдемо до найважливішої частини будь-якого проєкту з розробки: пошуку правильного партнера.
Як вибрати правильного партнера з розробки для створення додатка доставки на замовлення
Більшість засновників оцінюють партнерів з розробки за трьома критеріями:
- Естетику портфоліо
- Ключові слова щодо технологічного стеку
- Годинна ставка
Жоден із цих критеріїв не дає вам необхідної інформації. Важливо, чи створювала команда раніше системи доставки на замовлення та чи вміє вона застосовувати цей досвід у нових проєктах.
Є один сигнал, на який варто звернути увагу: чи проводить команда ретельне дослідження, перш ніж написати хоча б одну рядок коду?
Коли Stfalcon співпрацював із Nova Poshta Shopping — підрозділом електронної комерції «Нової Пошти», провідної служби експрес-доставки в Україні, — завданням було перепроектування. Існуюча платформа мала проблеми з зручністю використання, і замовник прагнув отримати кращий інтерфейс.
Ми могли б почати з макетів, але натомість наша команда розпочала з поглиблених інтерв’ю з користувачами, повного огляду сервісу — від реєстрації до отримання посилки, аналізу статистичних даних та вивчення скарг у службі підтримки.
Отримані висновки визначили рішення, яких не вдалося б досягти жодною дизайнерською інтуїцією. Сторінка «Посилки» була повністю перероблена у повнофункціональний особистий кабінет. У результаті ми замінили несправну сторінку «Посилки», додали інтегрований із Zendesk модуль запитань і відповідей та реструктурували транзакційні листи, щоб користувачі могли відстежувати відправлення, взагалі не входячи в систему.
Саме такої якості досліджень слід шукати в партнера з розробки, і це найшвидший спосіб з’ясувати, чи команда вже створювала подібні системи раніше, чи лише навчається на вашому проєкті.
Підсумок: 3 запитання, які слід поставити потенційному партнеру
Доставкові додатки зазнають невдачі, коли команда недооцінює складність, що ховається за оманливо простою поверхнею. Shyp мав 62 мільйони доларів, висвітлення в пресі та продукт, який користувачі щиро любили. Проте він все одно припинив роботу, оскільки бізнес-модель та інфраструктура так і не були належним чином узгоджені.
Хороша новина полягає в тому, що цю проблему можна вирішити, якщо підійти до неї з правильною ментальною моделлю та з партнером, який вже стикався з подібним раніше.
Найголовніше — переконатися, що ваш партнер точно знає про конкретні виклики, пов’язані з додатками для доставки, а не лише про те, як запустити додаток для доставки.
У Stfalcon ми знаємо, як створити додаток для доставки, і це наш досвід з перших рук. Тож якщо ви хочете обговорити свій проєкт з досвідченою командою, ми з радістю допоможемо: просто домовтеся про дзвінок, і подивимося, куди це нас приведе.
Плануєте модернізувати або створити додаток для доставки на замовлення?
Давайте поговоримо та визначимо ваш наступний крок
Аліна
Менеджерка з роботи з клієнтами
Поширені запитання
Чи розробляли ви раніше саме додатки для доставки?
Так, наша команда розробила додатки для кур’єрів та клієнтів, які залишаються синхронізованими навіть у зонах без покриття, що включає офлайн-режим, автоматичне вирішення конфліктів та час прибуття (ETA), який оновлюється на основі даних у реальному часі, а не приблизних оцінок.
Як виглядає ваш процес перед початком розробки?
Перед початком будь-якого проектування чи кодування ми аналізуємо кожен тип користувачів, можливі сценарії збоїв, модель даних та ризики інтеграції. У результаті цього етапу створюються технічна специфікація, журнал архітектури та реєстр ризиків.
Чи маєте ви готові компоненти для основних функцій доставки?
Так, маємо. Логіка диспетчеризації, відстеження в режимі реального часу, процеси оформлення замовлень та оплати — це готові компоненти, які ми використовуємо в поточних проєктах. Ми адаптуємо їх до ваших потреб, при цьому все, що розгортається у вашій кодовій базі, належить вам. Як результат, ви не зіткнетеся з простроченням термінів або перевищенням бюджету.
