Limits I own

The demo, and what changes for a real client

Every technical page already says where its system stops. Spread across eight pages, those notes read like excuses. Together they are a design decision: the demo has to open for anyone, and that forces me to switch off things a real business keeps on.

Public demo mode

A visitor has to be able to open everything without creating an account. So the access policies are deliberately open and there is no user session. Everything in this table is a choice, not an oversight, and the right-hand column is what gets quoted when the system belongs to someone.

Area	In this demo	For a real client
Authentication	None. Any visitor walks in with a four-character room code.	Supabase Auth, a session per person, signed in on the team's own phones.
Data isolation	By demo room. Each visitor sees only theirs, and rooms are deleted after six hours.	By company, with RLS tied to the account instead of a code in the address bar.
Roles and permissions	No roles. Whoever opens the room can do everything, including what only a manager would.	Owner, manager and staff, with the sensitive operations (voids, clock corrections, price changes) closed to the right role.
Payments	Takeaway records the method and marks the order paid. No money moves.	Real MB WAY, card or terminal, with an automatic refund when the house rejects an order.
Certified invoicing	Not there. The totals are arithmetic, not fiscal documents.	Integration with certified invoicing software, which is where an invoice has to be born.
Customer notifications	The status changes on screen. Nobody receives a message.	SMS or WhatsApp when the order leaves, and reservation confirmation by message.
Deliveries	Three fixed zones, each with its own fee and minimum. The route groups by zone, not by address.	Radius computed per address and the route ordered through a mapping API.
Point of sale	Sales are born inside the house, in orders and takeaway.	A link to the client's POS, so food cost and labour run on real sales.
Clock terminal	PINs are printed on screen, otherwise nobody can try the terminal.	PIN stored hashed, tablet fixed to the wall, and an export to payroll.
Hardware	A browser, on any screen. Kiosk mode exists but it is a web page.	Tablets in the kitchen, a pass screen and a ticket printer.
Data lifetime	Everything you write is deleted six hours later. It is a demo, not an archive.	Retention agreed with the client, backups, and history that does not delete itself.
Monitoring	Demo environment. If it stops overnight, it stops.	Alerts, error logging, and a plan for when the database does not answer.

Authentication

In this demo: None. Any visitor walks in with a four-character room code.
For a real client: Supabase Auth, a session per person, signed in on the team's own phones.

Data isolation

In this demo: By demo room. Each visitor sees only theirs, and rooms are deleted after six hours.
For a real client: By company, with RLS tied to the account instead of a code in the address bar.

Roles and permissions

In this demo: No roles. Whoever opens the room can do everything, including what only a manager would.
For a real client: Owner, manager and staff, with the sensitive operations (voids, clock corrections, price changes) closed to the right role.

Payments

In this demo: Takeaway records the method and marks the order paid. No money moves.
For a real client: Real MB WAY, card or terminal, with an automatic refund when the house rejects an order.

Certified invoicing

In this demo: Not there. The totals are arithmetic, not fiscal documents.
For a real client: Integration with certified invoicing software, which is where an invoice has to be born.

Customer notifications

In this demo: The status changes on screen. Nobody receives a message.
For a real client: SMS or WhatsApp when the order leaves, and reservation confirmation by message.

Deliveries

In this demo: Three fixed zones, each with its own fee and minimum. The route groups by zone, not by address.
For a real client: Radius computed per address and the route ordered through a mapping API.

Point of sale

In this demo: Sales are born inside the house, in orders and takeaway.
For a real client: A link to the client's POS, so food cost and labour run on real sales.

Clock terminal

In this demo: PINs are printed on screen, otherwise nobody can try the terminal.
For a real client: PIN stored hashed, tablet fixed to the wall, and an export to payroll.

Hardware

In this demo: A browser, on any screen. Kiosk mode exists but it is a web page.
For a real client: Tablets in the kitchen, a pass screen and a ticket printer.

Data lifetime

In this demo: Everything you write is deleted six hours later. It is a demo, not an archive.
For a real client: Retention agreed with the client, backups, and history that does not delete itself.

Monitoring

In this demo: Demo environment. If it stops overnight, it stops.
For a real client: Alerts, error logging, and a plan for when the database does not answer.

What does not change

The data model, the rules enforced inside the database and the arithmetic done on the server are the same on both sides. A price is still born on the server, a table is still refused by a Postgres constraint, and a batch still leaves by the nearest expiry date. That is the part that takes time to build. The rest is integration.

Open the house Talk to me