Ресторан, інтернет-магазин і доставка: одна система чи три продукти?

Ресторану з власним маркетом і доставкою зазвичай приносять три окремі пропозиції: сайт ресторану, інтернет-магазин і застосунок доставки. Ми опинилися в такій ситуації з LavShash і натомість спроєктували одну систему з трьома сценаріями для клієнта. Розбираємо, що в такій системі спільне, що кожен канал залишає собі, де потрібні застосунки, що будувати першим і коли три окремі продукти справді кращі.

КОРОТКО

Одна система, три сценарії

Якщо бізнес продає через ресторан, магазин і доставку, йому потрібна одна система внизу й окремий сценарій для кожного каналу згори. Каталог, залишки, клієнти, замовлення та адмінка існують в одному примірнику. Інтерфейси різні, бо людині, яка купує продукти, замовляє вечерю чи бронює стіл, потрібні різні речі. Три окремі продукти здаються дешевшими на старті й коштують дорожче кожного наступного місяця.

Ми дійшли до цього на проєкті LavShash: у бізнесу були ресторан, гастромаркет приблизно від 2 000 до 3 000 товарів і власна доставка. Більшість пропозицій, які він отримував, будувалися за однією схемою: сайт ресторану, інтернет-магазин і продукт для доставки, кожен окремо. Ми запропонували одну цифрову екосистему навколо трьох сценаріїв клієнта, спроєктували її та зробили сайт, маркет і нативні застосунки доставки для iOS та Android. Система збудована й готова, запуск відкладено.

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

Три продукти під одним логотипом для клієнта залишаються трьома продуктами.

ТРИ КОШТОРИСИ

Чому власнику приносять три пропозиції

Поділ зазвичай задає ринок, а не сам бізнес. Студія, яка робить сайти ресторанів, рахує сайт ресторану. Команда e-commerce рахує магазин. Студія застосунків рахує застосунок. Кожна пропозиція розв'язує завдання, яке стоїть перед нею. Простір між трьома продуктами при цьому не належить нікому.

А саме в цьому просторі й живе бізнес із кількома каналами. Страва є в меню ресторану і в доставці. Банка соусу стоїть на полиці маркету й потрапляє в замовлення додому. Та сама родина приходить до ресторану в суботу, замовляє доставку в середу й купує продукти онлайн у неділю. Якщо три продукти зроблені окремо, кожен такий момент стає питанням синхронізації: хто змінює ціну в трьох місцях, яка система знає клієнта, де зберігається історія замовлень.

Зрештою інтегратором стає сам власник. Співробітники переносять дані між адмінками, бухгалтер зводить три набори звітів, а кожна нова ідея (програма лояльності, подарункова картка, спільне замовлення) стає проєктом у трьох кодових базах і трьох договорах. На LavShash ми бачили, що роздільна модель технічно закрила б найближчі завдання, але в клієнта опинилося б кілька незалежних цифрових продуктів, які просто належать одному бренду.

Наш підхід починається на крок раніше. Ми дивимося на бізнес цілком, знаходимо, де його канали справді різні, а де вони частини однієї системи, і лише потім проєктуємо інтерфейси навколо цієї логіки. Та сама думка в загальнішому вигляді є в статті Більшості компаній потрібний не новий сайт, а нова структура.

СПІЛЬНЕ ЯДРО

Що існує один раз, а що окремо

Корисне запитання звучить не «один сайт чи три», а «які дані й правила належать бізнесу, а які каналу». Перша група має існувати один раз. Друга може відрізнятися настільки, наскільки потрібно кожному каналу.

Їжа додає деталі, яких немає у звичайній електронній торгівлі. За стравою стоїть кухня, у якої є години роботи, завантаження й меню, що може змінюватися щодня. У товару маркету є фізичний залишок, термін придатності, а в частини позицій ціна за вагу. Добре спільне ядро тримає і те, і інше в одному каталозі з різними правилами доступності, тож менеджер змінює позначку про алерген один раз, і вона правильна і на сторінці ресторану, і в маркеті, і в застосунку.

Той самий принцип для роздрібу, опту й партнерів ми описали в статті Коли e-commerce стає бізнес-системою. Там ідеться про ціни за акаунтами й розподіл залишків між торговими каналами. У ресторанному бізнесі больові точки інші: час кухні, зони доставки та клієнт, який за один тиждень встигає поїсти в залі, замовити додому й купити продукти.

У LavShash кожна частина зберегла свою логіку та свої сценарії, а ззовні все залишалося одним брендом на спільній архітектурі. Гастромаркет усередині був повноцінним інтернет-магазином: категорії, пошук, фільтри, картки товарів, кошик і оформлення замовлення, тобто саме те, чим займається наша розробка інтернет-магазинів. Спершу магазин зробив на Magento попередній підрядник, а ми перебудували його на Laravel навколо бізнес-правил; чому і що це змінило, розповідаємо в статті Чи йти з Magento у 2026 році.

ОДИН КЛІЄНТ

Один акаунт, одна історія

Уявіть постійного клієнта. У суботу він купує в маркеті сир і вино. У середу замовляє вечерю додому. У п'ятницю приходить до ресторану з друзями. За трьох окремих продуктів бізнес познайомився з трьома незнайомцями. За однієї системи він знає одну людину з однією історією.

Різниця помітна там, де це важливо власнику:

• Сервіс. Застосунок доставки вже знає адресу з останнього замовлення в маркеті, а скаргу на доставку видно поруч із візитами клієнта до ресторану.
• Розсилки. Один запис про згоди вирішує, кому можна надсилати новини й пропозиції, замість трьох списків із трьома наборами правил відписки.
• Лояльність. Бали, подарункові картки чи пропозиція до дня народження працюють в усіх каналах, бо їх є до чого прив'язати.
• Цифри. Бізнес бачить, скільки клієнтів користуються більш ніж одним каналом і скільки вони витрачають загалом. Три окремі бази без ручного зіставлення на це запитання не дадуть відповіді.

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

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

ДОСТАВКА

Доставка як окремий продукт

Доставку недооцінюють частіше за інші канали. На сайті ресторану вона зазвичай починається як сторінка меню з номером телефону. Коли замовлень стає більше, вона перетворюється на сервіс зі своїми правилами: зони, мінімальна сума, часові слоти, завантаження кухні, кур'єри, статуси замовлення й повернення.

У LavShash ми від самого початку не вважали доставку сторінкою меню. Ми спроєктували її як повноцінний сервіс: сайт плюс нативні застосунки для iOS та Android, де людина може вибрати страви, оформити замовлення й взаємодіяти із сервісом, хоч у ресторані, хоч удома.

Логіку доставки в бізнесі з кількома каналами визначають п'ять запитань:

1. Чи можна в одному замовленні поєднати страви кухні й товари маркету? Звучить зручно, але в готової їжі коротке вікно, а замовлення з маркету можна зібрати за кілька годин. Одні дозволяють це з одним часом доставки, інші ділять на два замовлення з однією оплатою.
2. Хто вирішує, який слот доступний: кухня чи кур'єр? Якщо кухня зайнята на 19:00, доставка має перестати пропонувати 19:30, а не приймати замовлення й потім вибачатися.
3. Які зони і за якою ціною? Зони й мінімальна сума замовлення належать до бізнес-правил і змінюються. Їм місце в адмінці, де їх редагує менеджер, а не в коді.
4. Що клієнт бачить після оплати? Прийнято, готується, в дорозі, доставлено: кожен статус або надсилає бізнес, або потім пояснює телефоном.
5. Як влаштовані повернення? Відсутній товар у замовленні з маркету й холодна страва потребують різної обробки, але обидва випадки мають іти через одну історію замовлень.

Власники часто запитують, чи потрібна власна доставка, якщо є агрегатори. Агрегатори дають охоплення, і багато ресторанів працюють з обома варіантами. Ціна агрегатора складається з комісії з кожного замовлення й стосунків із клієнтом: у США тарифи DoorDash Marketplace станом на жовтень 2026 року беруть із ресторану 15%, 25% або 30% із замовлення на доставку, а клієнт залишається клієнтом платформи. Власний канал доставки залишає клієнта, дані й правила в бізнесу. Водночас він має окуповуватися, тому йому місце на тому самому ядрі, що й усе інше, а не в ролі четвертого продукту.

Доставка перестає бути сторінкою меню, щойно замовлення починають повторюватися.

ТОЧКИ ВХОДУ

Головна сторінка не головний вхід

У системи з трьома сценаріями виникає практичне запитання: де клієнт у неї входить? За звичкою всіх відправляють на головну й пропонують вибрати. Але більшість людей приходять із вужчим наміром: конкретний товар, страва, доставка на сьогодні або сам ресторан.

У LavShash ми не вважали головну сторінку обов'язковою точкою входу. Пошуковий трафік потрапляв одразу в потрібну частину продукту: людина, яка шукала товар, опинялася в гастромаркеті, той, хто шукав доставку, потрапляв у доставку, а той, хто шукав ресторан, приходив у ресторан. Далі користувач залишався всередині тієї самої екосистеми. Так ми поєднали дві речі, які часто тягнуть у різні боки: глибоку спеціалізацію кожного розділу й цілісність єдиного продукту.

Для бізнесу, який планує свою систему, з цього випливають конкретні рішення:

• один домен бренду з зрозумілими розділами для маркету, доставки й ресторану, у кожного свої сторінки під свої запити;
• навігація, яка дає змогу переходити між сценаріями без втрати акаунта й кошика;
• головна сторінка як перехрестя для тих, хто прийшов за назвою бренду, а не ворота, через які мають пройти всі.

Три окремі домени ділять присутність бренду в пошуку, а кожне перехресне посилання перетворюється на перехід на інший сайт. Один домен із трьома розділами тримає клієнта в одному місці й дає кожному розділу говорити мовою своїх відвідувачів.

ЗАСТОСУНКИ ЧИ ВЕБ

Нативні застосунки чи мобільний веб?

Власникам часто пропонують по застосунку на кожен канал. З нашого досвіду, зазвичай вистачає одного, а в частині бізнесів не потрібно жодного. Перевірка проста, це частота: застосунок заслуговує на місце в телефоні, коли полегшує дію, що повторюється. Повторити замовлення вечері на збережену адресу якраз така дія. Раз на місяць подивитися інтер'єр ресторану чи каталог маркету вже ні.

Тому в LavShash доставка отримала нативні застосунки для iOS та Android, а ресторан і гастромаркет жили у вебі. Доставка ніколи не мала відчуватися мобільною версією сайту ресторану. Тому, хто замовляє часто, потрібна швидкість: його адреса, його останнє замовлення, спосіб оплати й статус, за яким можна стежити.

Мобільний веб за останні роки помітно виріс. Починаючи з iOS та iPadOS 16.4 вебзастосунок, доданий на екран «Додому», може запитувати дозвіл на push-сповіщення, про це команда WebKit в Apple оголосила разом із цим релізом. Маркету чи ресторану швидкий мобільний сайт, який можна встановити як вебзастосунок, закриває більшість завдань за частку вартості застосунку в магазині застосунків. Apple зі свого боку теж ставить планку: правила перевірки App Store вимагають, щоб застосунок був чимось більшим, ніж перепакований сайт, тож загорнути сайт в оболонку застосунку не вийде.

Як вибирати на практиці:

Ми робимо нативні застосунки на Swift і Kotlin або один застосунок на React Native, залежно від того, що потрібно продукту, разом із серверною частиною й адмінкою, як описано на сторінці розробки додатків; повноцінний застосунок зазвичай займає від 10 до 20 тижнів. Для бізнесу з кількома каналами головне те, що застосунок стає ще одним інтерфейсом до того самого ядра, без власного каталогу. Ширше рішення, зокрема прогресивні вебзастосунки, розібране в статті Коли бізнесу реально потрібен мобільний застосунок?

ВИТРАТИ

Скільки коштують три продукти в роботі

Усі порівнюють ціну розробки, хоча вона говорить найменше. Бізнес із кількома каналами платить за свої цифрові продукти щомісяця, і ось як дві моделі виглядають на роботі, яка ніколи не закінчується:

Застосунки додають шар витрат, який нікуди не зникає. Станом на жовтень 2026 року програма розробників Apple коштує $99 на рік, а Google Play бере разовий реєстраційний внесок $25. Обидва магазини застосунків підвищують технічні вимоги за графіком: з 28 квітня 2026 року застосунки, що завантажуються в App Store Connect, мають збиратися в Xcode 26 з iOS 26 SDK, а з 31 серпня 2026 року нові застосунки й оновлення в Google Play мають бути націлені на Android 16 (API level 36). Застосунок доводиться оновлювати щороку, навіть якщо в бізнесі нічого не змінилося. У схемі з трьох продуктів саме застосунок доставки найчастіше залишається без господаря.

Одна система дорожча в проєктуванні. Спільне ядро, модель акаунта й логіку замовлень треба продумати до того, як намальовано перший екран, і ця робота видна вже в першому кошторисі. Окуповується вона на другий рік і кожен наступний, коли бізнес додає канал, змінює меню чи запускає програму лояльності, не замовляючи три проєкти.

Для орієнтиру наші стартові ціни станом на жовтень 2026 року: інтернет-магазин від $25 000, мобільний застосунок від $30 000, діджиталізація бізнесу від $15 000. Система такого типу поєднує частини всіх трьох, тому справжній кошторис з'являється після того, як бізнес розібрано. Решта цін зібрана на сторінці цін.

Найдешевший кошторис на старті рідко дає найдешевшу систему в роботі.

ПОРЯДОК

Що будувати першим

Одна система не означає, що все будується одразу. Вона означає, що ціле проєктується заздалегідь, а будується в порядку, який рано дає користь. Ми радимо таку послідовність:

1. Розібрати бізнес. Канали, товари, залишки, клієнти, кухня, кур'єри, а також системи обліку й каси, які вже працюють. Стратегічна сесія дає першу відповідь за дві або три години, а discovery-фаза перетворює її на документи, прототип і кошторис.
2. Спроєктувати спільне ядро. Каталог, правила доступності, акаунт клієнта, модель замовлення й адмінка. Саме ця частина робить наступні канали дешевими.
3. Запустити сценарій, на який уже є попит. Для одного бізнесу це маркет, для іншого доставка. Перший канал допомагає оплатити наступні.
4. Додати другий і третій сценарії на тому самому ядрі. Кожен отримує свій інтерфейс, але жоден не отримує свою базу.
5. Додати застосунки, коли видно повторну поведінку. Застосунок доставки має сенс, коли до неї повертаються, і на той момент ядро вже віддає йому дані.

Порядок залежить від бізнесу. У LavShash усі три сценарії проєктувалися разом, від Figma до коду, і були збудовані: сайт, маркет і нативні застосунки доставки. Система готова, запуск відкладено, а наша впевненість у тому, що одна екосистема служить трьом сценаріям краще за три продукти, не змінилася.

Хто будує, важить не менше, ніж порядок. Такій системі потрібна одна команда, яка розуміє бізнес-логіку всіх каналів: фронтенд- і бекенд-розробники, мобільний розробник, дизайнер і людина, яка відповідає за архітектуру. Ми збираємо такі команди з людей, яких знаємо й перевірили, під проєкт із фіксованим обсягом або як виділену команду розробки, яка залишається з продуктом місяць за місяцем. У будь-якому форматі код і розгортання передаються вам за договором, і система належить бізнесу. Інженерний бік таких платформ описано на сторінці розробки вебзастосунків, а ширшу роботу з перенесення процесів в одну систему на сторінці діджиталізації бізнесу.

КОЛИ ОКРЕМО

Коли окремі продукти правильніші

Одна система підходить не завжди. Окремі продукти виправдані в чотирьох ситуаціях:

• Канали насправді є різними бізнесами. Різні бренди, різна аудиторія, часом різні власники. Якщо маркет через рік можна буде продати окремо, його система має вміти піти разом із ним.
• Канал працює як експеримент. Якщо доставка запускається як тест на три місяці, агрегатор або простий інструмент замовлення обійдуться дешевше, ніж вбудовування в ядро. Перенести канал у систему можна, коли він себе доведе.
• Ресторану треба лише запрошувати. Сайту з меню, фотографіями й віджетом бронювання від сервісу бронювання може вистачити, і ділити з магазином майже нічого.
• Операції не перетинаються. Немає спільних товарів, спільних клієнтів і спільних залишків. Тоді інтеграція коштує більше, ніж заощаджує.

Навіть у цих випадках варто заздалегідь вирішити, де живуть дані клієнтів і кому вони належать: окремі клієнтські бази потім найважче об'єднати.

Будь-якому підряднику варто поставити просте запитання: якщо через два роки ми додамо четвертий канал, що зміниться у вашій системі? Якщо відповідь звучить як «ще один проєкт такого самого розміру», бізнес купує продукти. Якщо відповідь «новий інтерфейс на наявному ядрі», він купує систему.

FAQ

Джерела

• DoorDash for Merchants: тарифи Marketplace і комісії
• Apple Developer Program: вартість участі
• Довідка Google Play Console: реєстраційний внесок
• Apple: вимоги до публікації в App Store
• Android Developers: вимоги до target API level у Google Play
• Apple: правила перевірки App Store, розділ 4.2 Minimum Functionality
• WebKit: Web Push for Web Apps on iOS and iPadOS