MESO.
Dwie aplikacje,
jeden ekosystem gastro.

MESO to franczyzowy koncept „Smart Asian Comfort” — japoński comfort food w modelu, który oszczędza na czynszu i personelu, a inwestuje w produkt. Operacyjnie wygląda to tak: jedna Kuchnia Centralna produkuje buliony, marynaty i sosy, a sprzedają 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.

Zamiast naginać gotowce, zbudowaliśmy własny ekosystem. Od zera.

Meso Delivery to instalowalna aplikacja PWA do zamawiania z dostawą i odbiorem. Własny kanał sprzedaży zamiast prowizji 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. Webhook płatności Przelewy24 wyzwala submission do POS API; jeśli POS jest niedostępny, zamówienie ląduje w kolejce retry z backoffem, a idempotentność (external_order_id) gwarantuje, że ponowienie nie stworzy duplikatu.

MESOpos nie jest zwykłą kasą. 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 nie wystarczy wiedzieć ile czego jest. Trzeba wiedzieć która partia i do kiedy. 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żę na poziomie pozycji menu — na żywo, nie w kwartalnym arkuszu.

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 klient API, nie nowy system.

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.

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. Migracja do monorepoTurborepo, współdzielone pakiety, jeden pipeline.
7. Jakość150+ testów, Sentry, smoke testy na produkcji.
8. Utrzymanie i rozwójIteracje, poprawki i monitoring przez cały czas życia produktu na produkcji.

Bez przekazywania między PM, analitykiem, designerem i developerem. Jedna osoba, która zna ten ekosystem od pierwszego dnia — każda kolejna iteracja jest tańsza i szybsza, bo nikt nie musi się od nowa uczyć kontekstu.