The software behind the counter.
Terminals, scanners, receipt printers, label printers, card readers and kiosks. Hardware integration is where a great deal of retail and hospitality software quietly falls over.
- Offline first
- it works when the network does not
- Real hardware
- tested on the actual devices
- Queued
- nothing lost on reconnect
Who this is for
You probably need this if…
01
The internet goes down and trading stops
A cloud-only system means an outage at somebody else's data centre becomes a closed till at your counter.
02
The printer works on one machine
It was configured by hand on one device and nobody wrote down how. The second site has never printed a receipt correctly.
03
Stock is right in the system and wrong on the shelf
Two terminals, two sessions, and a sync that picked a winner nobody ever agreed to.
What this covers
The work, in detail.
7 capabilities
01
POS terminal software
Interfaces built for a counter: fast, touch-first, and usable by somebody who started yesterday with a queue in front of them.
02
Peripheral integration
Receipt and label printers, barcode and QR scanners, cash drawers, scales and customer-facing displays.
03
Card reader integration
Certified payment terminals, tip flows, refunds at the counter, and what happens when a reader disconnects mid-transaction.
04
Kiosk & self-service
Locked-down devices, session timeouts, accessibility at a screen somebody is standing in front of, and remote recovery when one wedges.
05
Offline operation
A full local store with queued operations, so trading continues through an outage and reconciles cleanly once the connection returns.
06
Device fleet management
Provisioning, configuration and staged updates across sites, without anybody having to drive to each location with a USB stick.
07
Edge sync
Local-first data with explicit conflict resolution, so two terminals editing the same stock do not produce two different answers.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
The device is the source of truth while offline
A terminal must be able to trade alone and reconcile later. Anything else makes your revenue dependent on somebody else's uptime.
02
Test on the real hardware
Emulators do not reproduce a printer that jams, a scanner that double-reads, or a card reader that drops at exactly the wrong moment.
03
Design for the person with a queue
Counter software is used under social pressure. Fewer taps and a forgiving undo matter far more than anything on the settings screen.
04
Update in stages
Application and firmware updates roll out to a pilot site first. A bad update across an entire fleet makes for a very long day.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Devices
- Android and iOS terminals, Star and Epson printers, Zebra scanners
- Payments
- Stripe Terminal, Square, certified card readers
- Local data
- SQLite, local-first sync, queued operations
- Fleet
- Staged rollout, remote configuration, device telemetry
Where this shows up in delivery
- OneHubPOS runs on point-of-sale hardware and keeps ecommerce stock in step with the counter in both directions.
- Larder and InvtoryX are built around stockrooms with unreliable signal, so offline operation is the default rather than a fallback.
- We test on the physical devices, because the failures that matter are precisely the ones an emulator cannot produce.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about devices & edge.
- Do we have to buy new hardware?
- Usually not. Most current terminals and printers are supported, and we confirm your exact models in week one before anybody commits to buying anything.
- What happens during an internet outage?
- Trading continues. Operations queue locally and sync when the connection returns, with reconciliation reporting anything that conflicted while you were offline.
- Can you support several locations?
- Yes, including per-site configuration, staged updates and central reporting across all of them.
- Who handles payment certification?
- We build against certified readers from the processor, which keeps the certification burden with them rather than with you. That is deliberate, and it is the cheaper path by a wide margin.
Related reading
Written on this, by us.
Engineering · 7 min read
Offline-First Is Not a Feature, It Is a Decision You Make on Day One
Software used in a stockroom, a basement or behind a fridge will lose its connection. Retrofitting offline support is one of the most expensive changes in mobile development.
Data & Integration · 8 min read
What POS Integration Actually Costs a Multi-Location Restaurant
Online ordering that doesn't talk to your POS costs you ninety minutes a night and a food cost number you can't trust. Here's what the integration involves and what it's worth.
Engineering · 9 min read
Native vs Cross-Platform Mobile Development in 2025
React Native, Flutter or native iOS and Android. What each one actually costs you, and the handful of cases where the answer is not close.
Usually combined with
All practice areas →Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits