Keep the details intact.
Can changes, modifiers and allergy notes stay clear when more than one person is working on an order?
Work / First application
A restaurant shift is a real test.
The first swiftlabs.xyz application is an experimental restaurant application, built on open source foundations. It brings a broad question into focus: can the tools a business depends on stay in that business’s hands?
Experimental · No production-readiness claim
The direction
Keep useful records under the owner’s control. Make access deliberate. Leave a clear path to recovery and to a different provider or maintainer.
For this experiment, staff devices are intended to use one shared restaurant service. They depend on reaching that service; independent disconnected operation and peer-to-peer replication are not established capabilities.
Questions from the floor
Follow the whole shift.
Make the handoff clear.
Does the right station receive the right information? Can staff distinguish a correction from a new order?
Close with confidence.
Can the team account for orders, adjustments and recorded tenders at the end of a shift?
Know the way back.
Can a business restore its records after a failure, understand what changed, and return to work?
Where things stand
An experiment, with questions still open.
The starting point
An open-source point-of-sale project was chosen as the starting point after my local installation and build trial. That is a starting observation, not proof of a complete restaurant workflow.
What still needs evidence
The fork’s current end-to-end behavior has not been verified for this site. Device usability, shared-order integrity, recovery, peripherals and payment integrations need their own evidence before stronger claims can be made.
Agent assistance remains a design direction. This experiment does not establish reliable autonomous operation or readiness for a live venue.
What would you put to the test?
I’m interested in the exceptions, handoffs and workarounds that shape a real service.
Share your perspective