When a restaurant asks whether a point-of-sale system works offline, they usually mean something more demanding than “the page still opens.” Can staff take an order, send it to the kitchen, close the bill, and print a receipt while the internet link is down?
That is the test I use for OrderRestro. The web app, API, and PostgreSQL database can run on a server on the restaurant’s local network. Devices connect to that server over LAN, so a lost WAN connection does not automatically stop core service.
Local network is part of the product
This design changes the failure boundary. A cloud-hosted service depends on the restaurant reaching the provider. A local deployment depends on the branch’s server, network, power, and backups. The software can keep working through an internet outage, but it cannot make a failed local server disappear.
That means an honest “offline-first” setup needs an operating plan: where the server lives, who updates it, how data is backed up, and how a restore is rehearsed. Remote access, email, webhooks, and other external integrations still need connectivity.
Test the real workflow
If you are evaluating POS software, do a controlled WAN-disconnect exercise. Start with an open shift, then place an order, send it to the kitchen display, bill it, and print. Record which steps still work and which optional functions are unavailable. Do not infer offline capability from a marketing page or a cached dashboard.
OrderRestro is self-hosted and open source under AGPL-3.0. Its repository documents the local-server setup. I share more about building dependable business software on RaktimRanjit.com.
Top comments (0)