Reliability

None of this is exotic. It is the ordinary, unglamorous work that keeps a service healthy, done consistently:

• More than one copy of the app is running at any time, so one of them failing does not take the service down with it.
• Every release is checked before and after it goes out. If those checks do not pass, the release puts the previous version back by itself rather than waiting for someone to notice.
• The database and your uploaded images are backed up every night, and we practise restoring from those backups rather than assuming they would work.
• Errors are collected and looked at. When something starts failing we generally find out from our own tooling, not from an angry phone call.
• We keep the moving parts few. The platform is deliberately small in scope — it manages orders, and it does not sit in the payment path — which means there is less that can go wrong.

Something will, eventually. Every service on the internet has bad days, and it is more honest to plan for them than to pretend otherwise.

When we know about a problem that affects you, we say so on the site itself — a notice at the top of the page, in plain words, rather than silence while you work out whether it is you or us. If we are doing planned work that might interrupt anything, we would rather tell you beforehand than surprise you mid-service.

And then we fix it. There is no queue to be triaged into and no ticket to chase — this is a small operation, and a problem that stops a restaurant taking orders is the most important thing happening that day.

This is the part worth understanding properly, because it is what makes an outage an inconvenience rather than an emergency.

We are not in the payment path. Diners pay you directly — your own payment QR, or cash or card at the counter — and money never passes through us. So if the Platform is unavailable, there is no payment stuck somewhere, nothing held up in transit, and nothing of yours sitting in our account waiting to be released. There is nothing for us to release.

And a restaurant that has taken orders on paper for a hundred years can take them on paper for an hour. Your kitchen, your staff, and your ability to serve and get paid do not depend on us being up. That is by design, and we would rather you knew it than discovered it.

Your menu, your orders and your settings are stored in a database that is backed up nightly, and the images you upload are backed up with it. If you ask us to remove something, we remove it.

One thing we would rather be straight about: usage statistics and session recordings — the diagnostic data described in our Privacy Policy — are not part of that backup set. Losing them would cost us insight into how the product is used; it would not cost you an order, a menu, or a record of what a diner asked for. We back up the things that would actually hurt you to lose.

You will not find an uptime percentage on this page, and that is deliberate.

Plenty of services publish a number like "99.9%" because it looks reassuring. We would rather tell you the truth: this is a small operation, the service will occasionally be slow or unavailable, and when that happens we work on it until it is fixed. Printing a figure would not make the service any steadier, and committing to one we could not always honour would be a worse thing to do to you than saying nothing at all.

So there is no service-level agreement here, no guaranteed response time, and no credit scheme. What there is instead is a short list of things we genuinely do, above, and a working email address, below. We would rather be judged on those.

If something is not working, we would genuinely rather hear about it than not — a report from someone actually using the product during a busy service is worth more than any amount of monitoring. Write to [email protected] and tell us what you were doing and what happened. It is a real inbox, read by the people who can fix it.