Ramlyon

Many restaurants, one platform

Every venue runs on the same deployment, and its data is isolated at the database layer, not by a filter someone has to remember. Each one gets its own address (yourcafe.ramlyon.com), its logo, colours and QR design, and a menu in up to 14 languages. Arabic and right to left are the default, not a translation.

Money the browser can't change

• Every amount is an integer in minor units (piastres), never a float.
• The POS and the web checkout show a total at once, then the server recomputes it from scratch, and that is the number saved.
• Every order is a frozen snapshot of names, prices, options, tax and service, so a price changed tomorrow never rewrites last week's reports.

Live screens without polling

A write fires pg_notify. One LISTEN connection per app instance builds the event once and fans it out to that venue's open tabs over server-sent events. Database work grows with writes, not with open screens: ten devices on all day cost the same as one.

Delivery addresses never ride the broadcast. The stream only says "delivery changed", and each screen re-reads what its role allows, so a chef or a driver never receives an address that isn't theirs.

Keeps working when the internet doesn't

The dashboard is an installable app. Orders, menu edits, customers and tables are written to a durable queue on the device and replayed when the connection returns:

• Replays are idempotent, so a retry never records an order twice.
• Changes to an order are sent as intentions ("mark ready", "add this item") and merged per line, so a waiter and the kitchen editing at the same second both survive.
• If the server refuses something done offline, the app rolls it back and says so.

A QR scan that costs zero queries

A menu scan used to cost five database reads. The page is now cached at Cloudflare's edge indefinitely and purged by host the moment the venue changes anything, so an edit shows at once and a scan usually costs nothing.

That only worked once the page stopped depending on the clock: "open" or "closed" is computed on the diner's phone from the venue's hours and timezone. I checked that logic against the server's across 10,752 cases, including daylight-saving changes.

Built for real counters

• Many tills run Windows 7, so the floor is Chrome 109, its last browser.
• Receipts and kitchen tickets print through the browser instead of raw ESC/POS, because cheap thermal printers mangle Arabic and the browser shapes it correctly.
• The POS keeps selling offline and prints without a round trip to the server.

Access that matches a restaurant

48 permissions across 14 areas, with 6 built-in roles: owner, manager, cashier, chef, waiter and driver. A chef can mark an item out of stock without being able to change its price. Every action passes four server-side gates: signed in, role, plan and an account in good standing. A feature the plan lacks is shown blurred with an upgrade, and a feature the role lacks isn't shown at all.

Billing that never holds data hostage

Two plans, Menu and Operations, with a 14-day trial, paid by InstaPay, mobile wallets or the EasyKash gateway. An unpaid account goes read-only after a 14-day grace period and is never deleted. Venues can export everything to Excel (14 sheets) or JSON at any time, and retention follows a published policy written against Egypt's data-protection law.

Running it

Hetzner servers through Coolify, behind Cloudflare, with images compressed on upload and served from R2. A health endpoint checks the database, R2, Cloudflare, email and Telegram, and a platform-owner console runs tenants, plans, payments and maintenance. I run it in production myself.

By the numbers

Built and launched	under 4 months, by one engineer
Codebase	~92,000 lines of TypeScript, 41 database models
Languages	14, Arabic first
Permissions	48, across 14 areas, 6 built-in roles
Analytics	6 pages, 40 metrics
Database reads per menu scan	5 → 0