[ Hospitality Infrastructure • FoodTech ]
LiveLa Brisa OS
An operating system for the dining floor.
La Brisa began as the system running one dining room — taking the order, getting it to the kitchen and settling the payment as a single path instead of four integrations. La Brisa OS is that system being generalised into a platform other venues can run, because the parts that break first under load are the same everywhere.
- One venue
- Footprint
- QR → kitchen
- Order path
- Stripe
- Settlement
- Covers per day
- Throughput
- Status
- Live in one venue · Platform in development
- Built for
- Today, a single hospitality venue. The platform is being built for independent operators and small groups.
Why it exists
A dining room has a hard throughput ceiling, and it is rarely the kitchen. It is the round trip: a guest waits for a server, the server walks the order to a terminal, the terminal prints to a pass, and any error in that chain costs a full table turn to correct.
Layered on top of that, an operator trading in Spain now has to produce invoice records that meet the VeriFactu regime — an obligation that is trivial to satisfy when the point of sale was designed for it, and expensive to retrofit when it was not.
La Brisa collapses that chain into a single path from the guest's own phone to the kitchen display. That path runs in a real dining room today; the work now is making it something a second and a tenth venue can run without a rebuild.
Friction
What breaks, in order.
- 01
The wait for a server
Nothing can be ordered until a member of staff is free. Demand arrives continuously; attention arrives in bursts.
- 02
The transcription step
The order is spoken once and typed once. Every modification repeats both, and each repetition is a place for the two versions to disagree.
- 03
The printed snapshot
A ticket at the pass is true at the moment it prints. A change made front of house afterwards has to be carried across the room by voice.
- 04
The cost of a correction
An error discovered at the pass is not a small error. It costs the table turn, at the hour when turns are the constraint.
- 05
Fiscal records added afterwards
An invoicing regime satisfied by an export job is a second source of truth. Reconciling it is cheap while volumes are small and expensive exactly when they are not.
Capabilities
Interactive QR service
Guests open the menu, order and pay from their own device, with no app install. The floor team keeps control of the room instead of relaying requests, and the order reaches the kitchen without a transcription step in between.
Real-time kitchen display
Orders land on the KDS as they are placed, with state synchronised across stations. Because the display reflects the order rather than a printed snapshot of it, a modification made front of house is visible at the pass instead of being shouted across it.
Integrated payment
Payment runs through Stripe against the same order record the floor and the kitchen worked from, so settlement reconciles against the service rather than against a separate till.
VeriFactu compliance — in development
The invoicing model is being built so that records satisfy Spain's VeriFactu requirements as part of the transaction itself, rather than as an export job afterwards. This is not shipped yet and should not be relied on for a live fiscal obligation.
How it is built
Event-driven state
Order state propagates as events and is reconciled rather than polled, which is what keeps a floor and a kitchen agreeing with each other during a service peak. This is what runs today.
Multi-tenant isolation — in development
The platform work is making each operator's data, configuration and billing surface provably separate, so one venue's load or mistakes cannot reach another. Until that lands, La Brisa runs as a single-tenant system.
Compliance as a data model concern
Fiscal requirements are modelled in the core rather than bolted to the reporting layer, because a record that has to be reconstructed after the fact is a record that can disagree with the sale.
Product decisions
What we chose, and what it cost.
01
One venue properly, before ten venues badly
The system was built against a real service before it was generalised, which is why it is honest about running in a single dining room today. The cost is obvious: there is no second customer yet, and the multi-tenant work is still ahead rather than behind.
02
Tenancy decided in the data model, not in the code
Isolation is being drawn at the schema boundary rather than enforced by whichever query happens to run. It is slower to reach a second venue this way. It is also the only version where reaching a tenth does not require a rewrite.
03
Reconcile events rather than poll for state
The floor and the pass converge on order state by exchanging events. That is more machinery than a refresh loop and it earns its keep only under a service peak — which is the only hour that decides whether the system is any good.
04
Compliance modelled as a transaction, not a report
Building the fiscal record into the sale is more work up front than exporting one later, and it constrains how the sale itself can be represented. In exchange, there is never a second version of a transaction to defend.
At a glance
- Category
- Hospitality operations system
- Sector
- Hospitality · FoodTech
- Deployment
- Single venue · Multi-tenant in development
- Fiscal regime
- VeriFactu · Spain (in development)
- Payments
- Stripe
In one line
One path from the table to the pass.
The order the guest places is the order the kitchen sees and the order the payment settles against — one record, no transcription, no printed snapshot going quietly out of date. That runs in a dining room today. The work now is making it something the next venue can run without a rebuild.
Evaluating La Brisa OS?
Tell us about the operation and the constraint you are up against. The brief takes about fifteen minutes and is composed entirely in your browser.