A restaurant that runs on its own software

Alsafi is a family-run Iraqi-Levantine restaurant on Hertzstraße in Heidelberg. Before this, ordering meant an aggregator: a commission on every plate, a customer relationship owned by somebody else, and a kitchen reading tickets from a system nobody there had chosen.

They now run on their own.

What "the whole thing" actually means

One codebase carries four different jobs, and each one has a different person on the other side of it.

• The guest deciding whether to come. Menu, lunch, story, hours and reviews, phone-first, because that is how people check whether a restaurant is worth the walk.
• The guest ordering. A funnel with modifiers and upsells, checkout, Stripe payment, tips, and live order tracking with a real estimate. This is the money path, and it is built to remove anxiety rather than to maximise a basket.
• The guest with an account. Low frequency, high stakes: get in, get the thing, get out.
• The people running the service. Sixty-six staff screens, a kitchen display read at a distance under time pressure, and the print surfaces the floor actually uses.

It installs from the browser onto a phone, a tablet, a Mac, a Windows PC or a Linux desktop. One codebase, no app store, no separate builds to keep in step.

The menu is a database, not a PDF

A hundred and three dishes sit across fifteen categories, each with its own variants and prices, and its own option groups for the choices a guest actually makes — the size, the side, the way it is cooked. The kitchen edits all of it. Nobody redraws a document.

Underneath each dish is the part German law cares about. Fourteen EU-regulated allergens and sixteen additive declarations are recorded per dish rather than per menu, checked against the same matrix the kitchen cooks from instead of a PDF nobody remembers to update. A guest can filter one allergen out, or filter the whole menu down to vegan, vegetarian or Halal, before they commit to an order rather than after.

Lunch runs on its own rotation, with its own dishes and its own week. A dish that has run out comes off the menu with one tap and returns the moment it is back — the guest sees it, the till sees it, and nobody has to remember to tell the other.

Ordering, paying, and knowing where the order is

Delivery is drawn as zones rather than a radius, because a street either is or is not somewhere the food arrives hot. Collection is a first option, not a fallback. A returning guest keeps their addresses; a first-time guest is not made to open an account to eat, and can claim the order into one afterwards if they want the history.

Payment is Stripe, with tips handled as their own line rather than folded into the total. Once the order is in, the guest gets a live status with a real estimate, and — if they allow it — a push notification when the kitchen changes it, so nobody sits refreshing a page to find out whether dinner is coming.

Refunds are the part that has to be right the first time. A refund row is written before Stripe is called and its own id is the idempotency key, so a retry, a double-click or a lost connection cannot refund the same order twice. The order's refunded total is derived from those rows rather than typed anywhere.

The room, as it actually is

The floor plan is in the system: two venues, twenty-one areas, three hundred and fifty-three tables. Reservations land against real tables rather than an abstract capacity, which is the difference between a booking system and a spreadsheet with a nicer form.

The floor, and the people on it

Terminals pair to the system rather than being trusted by being on the network — the till, the waiter phones, the kitchen screen each hold a device token, and the pairing codes and tokens are stored as hashes no client can read back. Staff sign in with a PIN, bcrypt-hashed, with lockout after repeated failures, because a till in a busy service is the least private keyboard in the building.

Roles are real. An owner's account and a floor account are not the same door, and the kitchen display shows tickets sized to be read across a hot line rather than a dashboard shrunk to fit.

Hours worked, kept the way the law wants them

The rota separates a manager's draft from what the team has actually been told, so a shift is either published or it is not. Against it sits the working-time record the Arbeitszeitgesetz asks for: beginning, end, duration and break, kept two years.

Corrections are the interesting part. Changing a time does not overwrite it — the original stays alongside the new one, with an author and a reason. A record that can be silently rewritten is not a record, and an auditor knows it.

The part most agencies quietly skip

Germany does not let a restaurant simply take money. Every transaction has to be signed by a certified technical security device, and the tax authority can ask for a DSFinV-K export covering ten years of trading.

That is built in. The platform talks to a BSI-certified TSE provider, composes the fiscal schema from the live specification rather than from memory, and exports the full DSFinV-K bundle on demand — with an audit trail of who exported which period, when, and the hash of exactly what they were given.

The rest of the fiscal picture is there because a tax inspector will ask for it. Each day closes into a Kassenabschluss, the Z-number that every transaction in the system belongs to. Cash movements that are not sales — the opening float, deposits, withdrawals, transit, counted differences, tips, returnables, vouchers — are recorded as their own kind of event rather than smuggled into turnover. And when the TSE itself goes down, the outage is logged with its time and cause and marked on any receipt issued during it, which is precisely what the AEAO requires and precisely what nobody remembers to build.

A signed sale cannot be deleted for a decade, so the code that produces one is written to be read by an auditor, not just to pass a test.

We do the same work in Egypt, for the Egyptian Tax Authority's e-invoicing, and in Saudi Arabia for ZATCA. The countries differ; the discipline does not.

Talk to us about a compliance-critical build

Nothing happens to an order without a name on it

Every order carries an append-only event log, and the events are not written by whoever happens to be holding the connection. Each one records who acted, in what role, from which surface, and why — a status change from the kitchen screen, an edit from the office, a refund with a reason attached.

The orders table itself is read-only to the admin interface. Every write goes through a server function, because those are the only callers that can establish who is acting. A direct write to the table would be recorded as the system doing it, and "the system did it" is not an answer anyone wants to give a tax inspector.

The restaurant's own marketing, in the restaurant's own hands

The site's content — hero, story blocks, gallery, events — is edited in the same admin as everything else, then published as a job rather than a live edit, so a half-finished sentence is never one refresh away from a guest.

Around it sits everything a restaurant otherwise rents: a blog, job postings with applications, guest feedback, support tickets, and trackable short links for print and QR so a flyer can be told apart from a table card. Google's own reviews sync into the same admin the fiscal exports live in. A weekly newsletter is assembled from that week's actual lunch specials rather than written from nothing, with double opt-in, one-click unsubscribe and a send log.

Guests who want a person get one: live chat with typing indicators and voice notes, kept as a conversation rather than a ticket.

Analytics that do not sell the guests

The restaurant can see what today looked like — revenue, orders, average order value, which dish gets the most attention, which hours are busy in its own timezone, where visits come from, and where a visit turns into something.

None of it is bought from a third party, and none of it follows anyone. Unique visitors are counted with short-lived salted hashes that are purged after two days; countries come from the edge rather than from a tracker. No fonts, icons or scripts are fetched from anyone else's server. That is a GDPR and content-security decision before it is a performance one, and it means a guest reading a menu is not quietly introduced to an advertising network.

The dashboard also draws its own line carefully: it counts orders for planning and says so outright, because the number that is legally binding lives in the Z-report, not here.

Trilingual, and Arabic properly

German is canonical. English and Arabic ship for every single string, and Arabic is full right-to-left: mirrored layout, logical properties, its own type stack. Not a translation bolted on at the end, which is what makes the difference between a site an Arabic speaker can use and one they merely can read.

Nothing is considered finished until it holds in light and dark, in left-to-right and right-to-left, and from a 375-pixel phone to a desktop.

Built to be checked

Four hundred and sixty-six test files. Accessibility verified with automated checks rather than by eye. WCAG AA as a constraint rather than an aspiration, with 44-pixel touch targets and reduced-motion honoured throughout.

What it costs to not own this

An aggregator can copy a menu. It cannot copy the family's hospitality, and it will not hand back the customer relationship. Every decision in this build was judged against one question: would a marketplace have done it this way? Where the answer was yes, we did something else.