MESO.
Dwie aplikacje,
jeden ekosystem gastro.

MESO był franczyzowym konceptem „Smart Asian Comfort” — japoński comfort food w modelu, który oszczędzał na czynszu i personelu, a inwestował w produkt. Operacyjnie wyglądało to tak: jedna Kuchnia Centralna produkowała buliony, marynaty i sosy, a sprzedawały je mobilne punkty — food trucki i kioski.

Ten model jest świetny biznesowo i bezlitosny technologicznie. Gotowe systemy POS zakładają restaurację z jedną kuchnią i jednym magazynem. Marketplace'y dostawowe biorą prowizję od każdego zamówienia i zabierają relację z klientem. A franczyza potrzebuje od pierwszego dnia czegoś, co zwykle mają dopiero sieci po latach: centralnej kontroli receptur, kosztów i zapasów w wielu lokalizacjach naraz.

Zbudowaliśmy więc własny ekosystem pod ten model. Od zera.

Meso Delivery to instalowalna aplikacja PWA do zamawiania z dostawą i odbiorem. Własny kanał sprzedaży bez prowizji dla marketplace'ów: menu z wariantami i dodatkami, koszyk z sugestiami, płatności BLIK/karty/Przelewy24, program lojalnościowy MESO Club i status zamówienia na żywo.

Wyzwanie #1 — zamówienie, które nie ma prawa zginąć.

Klient zapłacił, więc zamówienie musi dotrzeć do kuchni — nawet jeśli POS akurat nie odpowiada. Przewiń przez pięć realnych ekranów aplikacji i zobacz, co dzieje się pod spodem na każdym kroku: od webhooka płatności, przez kolejkę retry z idempotentnością, po status na żywo.

MESOpos to system operacyjny całej sieci — 11 modułów biznesowych w architekturze modular monolith, zaprojektowanej pod model: Kuchnia Centralna produkuje, punkty sprzedają.

Wyzwanie #2 — FEFO, czyli magazyn, który myśli datami.

W gastronomii przy każdym składniku liczy się, ile go jest, z której partii pochodzi i do kiedy jest przydatny. Każde przyjęcie towaru tworzy partię z datą przydatności; rozchód zdejmuje automatycznie z partii o najkrótszej dacie (First Expired, First Out). Kierownik punktu widzi nadchodzące przeterminowania, zanim staną się stratą.

Wyzwanie #3 — food cost bez Excela.

Receptury w MESO są zagnieżdżone: marynata wchodzi do bulionu, bulion do ramenu. Zmiana ceny jednego składnika w Kuchni Centralnej przelicza koszt każdego dania w całej sieci. Właściciel widzi marżę każdej pozycji menu na żywo.

Dwie działające aplikacje to za mało, jeśli mają rosnąć razem. Trzecim etapem była migracja do Turborepo z trzema współdzielonymi pakietami: @meso/core (typy, enumy, schematy Zod), @meso/api-client (typowany klient HTTP z retry i backoffem) i @meso/supabase.

Całość trzyma się jednej zasady architektonicznej: do bazy pisze wyłącznie POS API. Delivery i każdy przyszły kanał rozmawiają z POS przez REST. Nowy kanał sprzedaży to po prostu kolejny klient API.

POS aktywnie powiadamia Delivery o zmianach statusu przez webhooki podpisane HMAC-SHA256 z retry, a Supabase Realtime dostarcza status na ekran klienta w sekundę od kliknięcia kucharza w KDS. Synchronizacja menu działa w jedną stronę: edytujesz produkt raz, oba kanały są aktualne.

Zasada „nowy kanał sprzedaży to kolejny klient API” przeszła test szybciej, niż planowaliśmy. Po dwóch dniach pracy agent odbierał każde połączenie bez kolejki, linia działała 24 godziny na dobę, a zamówienia trafiały do kuchni bez udziału człowieka. W godzinach szczytu obsługa mogła zostać przy garnkach.

1. Discovery i specyfikacjaModel operacyjny KC + punkty przełożony na specyfikację funkcjonalną POS i spec PWA.
2. ArchitekturaModular monolith, kontrakty API, zasada „only POS writes”.
3. Design i build DeliveryPWA od landing page po checkout z Przelewy24.
4. Build POS11 modułów: KDS, magazyn FEFO, receptury BOM, CRM, pracownicy.
5. IntegracjaAPI v1, webhooki HMAC, kolejki retry, idempotentność.
6. Agent głosowy AIZamówienia telefoniczne 24/7: ElevenLabs + Twilio, worker na Cloudflare, dwukierunkowa komunikacja z POS.
7. Migracja do monorepoTurborepo, współdzielone pakiety, jeden pipeline.
8. Jakość150+ testów, Sentry, smoke testy na produkcji.
9. Utrzymanie i rozwójIteracje, poprawki i monitoring przez cały czas życia produktu na produkcji.

Bez przekazywania między PM, analitykiem, designerem i developerem — i bez długiej ścieżki decyzyjnej po stronie wykonawcy. Jedna osoba, która zna ten ekosystem od pierwszego dnia — każda kolejna iteracja była tańsza i szybsza, bo nikt nie musiał się od nowa uczyć kontekstu.