MESO.
Two apps,
one food-service ecosystem.

MESO is a “Smart Asian Comfort” franchise concept — Japanese comfort food in a model that saves on rent and staff, and invests in the product. Operationally it works like this: one Central Kitchen produces the broths, marinades and sauces, and mobile points of sale — food trucks and kiosks — sell them.

This model is great for business and merciless for technology. Off-the-shelf POS systems assume a restaurant with one kitchen and one stockroom. Delivery marketplaces take a commission on every order and keep the customer relationship. And a franchise needs, from day one, something most chains only get after years: central control of recipes, costs and stock across many locations at once.

Instead of bending the off-the-shelf tools, we built our own ecosystem. From scratch.

Meso Delivery is an installable PWA for delivery and pickup orders. Your own sales channel instead of marketplace commissions: a menu with variants and add-ons, a cart with suggestions, BLIK/card/Przelewy24 payments, the MESO Club loyalty program and live order status.

Challenge #1 — an order that has no right to get lost.

The customer has paid, so the order must reach the kitchen — even if the POS happens to be down. Scroll through five real screens of the app and see what happens underneath at every step: from the payment webhook, through the retry queue with idempotency, to live status.

MESOpos is not a regular register. It is the operating system of the whole chain — 11 business modules in a modular-monolith architecture designed for the model: the Central Kitchen produces, the points of sale sell.

Challenge #2 — FEFO, a warehouse that thinks in dates.

In food service it is not enough to know how much of something you have. You need to know which batch and until when. Every goods receipt creates a batch with an expiry date; stock is drawn automatically from the batch expiring soonest (First Expired, First Out). The site manager sees upcoming expirations before they become a loss.

Challenge #3 — food cost without spreadsheets.

Recipes in MESO are nested: the marinade goes into the broth, the broth into the ramen. Changing one ingredient’s price in the Central Kitchen recalculates the cost of every dish across the chain. The owner sees margin at menu-item level — live, not in a quarterly spreadsheet.

Two working apps are not enough if they are meant to grow together. Stage three was the migration to Turborepo with three shared packages: @meso/core (types, enums, Zod schemas), @meso/api-client (a typed HTTP client with retry and backoff) and @meso/supabase.

Everything follows a single architectural rule: only the POS API writes to the database. Delivery and every future channel talk to the POS over REST. A new sales channel is an API client, not a new system.

The POS actively notifies Delivery about status changes via HMAC-SHA256-signed webhooks with retry, and Supabase Realtime delivers the status to the customer’s screen within a second of the cook tapping the KDS. Menu sync runs one way: edit a product once, both channels are up to date.

“A new sales channel is an API client, not a new system” — that rule passed its test sooner than we had planned. The payoff was out of proportion to the effort: zero missed calls, a line open 24 hours a day and orders that land in the kitchen with no human involved — at peak hours nobody has to choose between the pot and the phone.

1. Discovery & specificationThe Central Kitchen + points operating model turned into a functional spec for the POS and a spec for the PWA.
2. ArchitectureModular monolith, API contracts, the “only POS writes” rule.
3. Design & build: DeliveryThe PWA from landing page to checkout with Przelewy24.
4. Build: POS11 modules: KDS, FEFO inventory, BOM recipes, CRM, staff.
5. IntegrationAPI v1, HMAC webhooks, retry queues, idempotency.
6. AI voice agentPhone orders 24/7: ElevenLabs + Twilio, a worker on Cloudflare, two-way communication with the POS.
7. Monorepo migrationTurborepo, shared packages, one pipeline.
8. Quality150+ tests, Sentry, production smoke tests.
9. Maintenance & growthIterations, fixes and monitoring for the product’s whole life in production.

No handovers between a PM, an analyst, a designer and a developer — and no long decision path on the vendor’s side. One person who has known this ecosystem since day one — every next iteration is cheaper and faster, because nobody has to relearn the context.