Software for the counter, the warehouse and the back room.
Some work needs a full keyboard, a barcode gun, a label printer and a screen that never shows a login page. We build desktop software for those stations.
Why some jobs still belong on a PC.
A cashier scanning two hundred items an hour, a receiving clerk labelling parcels, an accountant posting entries all day: these people need speed and hardware. A desktop app talks directly to scanners and printers, keeps working when the internet drops, and starts where the operator left off. It still syncs to the same system as your website and mobile app, so nothing lives only on one machine.
- Operators use barcode guns, label printers, scales or receipt printers.
- The station must keep working through internet outages.
- Speed per transaction matters more than a pretty interface.
- You want installs and updates that do not need an IT visit.
The station app owns the scanner, label printer and cash drawer. Every action is written to a local queue first, then synced to the central system. When the line drops, work continues and catches up later.
What is included in a desktop app
Operator screens
Keyboard-first layouts with shortcuts for every action, large readable states, and no mouse needed for the common path.
Hardware integration
Barcode guns, label and receipt printers, scales and cash drawers, configured per station and tested on your actual devices.
Offline resilience
A local database and an outbox. The station works through outages and syncs when the connection is back, with a visible queue.
Installer and updates
Signed installers for Windows and macOS, silent updates, and a fleet view showing which station runs which version.
How we build desktop
Modern web technology inside a native shell, with real hardware access.
- Native shell
- Electron or Tauri depending on footprint, with the interface shared with your web back office so screens do not drift apart.
- Device access
- Serial, USB and network printers through native bridges. Scanner input handled as a device stream, not as fake keyboard typing.
- Local-first storage
- SQLite on the station, an append-only outbox, and sync with idempotent operations so a replay never double-posts.
- Auto update
- Code-signed builds, staged rollouts by station group, and a rollback switch when a release misbehaves.
- Audit on the station
- Every scan, print and override is logged with operator and time, locally and centrally, for shrinkage and dispute resolution.
From the counter to a fleet of stations
- Phase 1
Observe
We stand at the station and time the current process. The bottleneck is usually not what the brief says.
- Phase 2
Design
Keyboard flows and hardware list agreed. A paper prototype of the main screen is tested by the operators.
- Phase 3
Build
One pilot station runs the app in parallel with the old process until the numbers match.
- Phase 4
Roll out and run
Remaining stations switched in groups, operators trained on the spot, updates pushed centrally after that.
Questions people ask
- Which hardware do you support?
- Any barcode gun that acts as a keyboard or serial device, Zebra and compatible label printers, ESC/POS receipt printers, common scales and cash drawers.
- What happens when the internet goes down?
- The station keeps working. Actions queue locally and sync when the line is back. The operator sees the queue size on screen.
- Can it run on the PCs we already have?
- Usually yes. We test on your lowest-spec machine and tune for it. Windows 10 and later, and current macOS, are supported.
Tell us what you need to build.
A short message is enough to start. We reply within 24 hours.