Service
Custom desktop application development
For the work a browser tab cannot do well.
Desktop is a deliberate choice, not a legacy one. It is right when the job is high-volume keyboard data entry, when local hardware is involved - scales, printers, scanners, biometric readers - or when the software must keep working with the internet down. Built for Windows, where most of this work actually happens.
The decision
When this is the right call.
Almost everything has moved to the browser, and mostly that is correct. Three things did not move well. The first is dense keyboard-driven data entry: an operator entering four hundred vouchers a day needs tab order, keyboard shortcuts and instant response that a web form rarely matches.
The second is hardware. Weighing scales, label and dot-matrix printers, barcode scanners in keyboard-wedge mode, biometric readers, COM-port devices. Browser access to these is either impossible or fragile enough that it becomes the thing support spends its time on.
The third is operating without a network. A counter that cannot bill when the connection drops is a counter that has stopped, and for many businesses that is not an acceptable failure mode. A desktop application with local data and background sync simply continues.
What you get
What the work covers.
Keyboard-first data entry
Tab order, shortcuts and in-place validation designed for someone who never touches the mouse and knows the form by muscle memory.
Local hardware
Scales, label printers, dot-matrix invoicing, scanners and biometric devices driven directly rather than through a browser shim.
Offline operation
A local database as the working store, with sync to the server when it is reachable and a clear conflict rule when it is not.
Multi-branch sync
Branches that operate independently and reconcile centrally, without requiring a permanent link to head office.
Exact arithmetic
Money as fixed-point decimal throughout. Floating point in a billing system is a rounding dispute waiting to be found.
Managed updates
Signed, versioned updates delivered and applied without a technician visiting each machine.
Stack
What we build it with.
Chosen per project. Nothing here is applied by default, and the team who will maintain it counts as much as the problem.
Application
.NET with WPF or WinUI for Windows, chosen for hardware access and deployment maturity rather than fashion.
Local data
SQLite or SQL Server LocalDB, with a migration path that survives a schema change on an offline machine.
Sync
An API shared with the web platform, so desktop and browser clients cannot diverge in their business rules.
Hardware
Serial, USB HID and vendor SDKs, tested against the devices actually on your floor.
Deployment
Code-signed installers with automatic update, and a rollback that works.
Comparison
Browser vs desktop client.
Desktop is a deliberate choice for a narrow set of jobs. Here is where each one actually wins.
| Aspect | Browser | Desktop client |
|---|---|---|
| Deployment | Nothing to install; everyone is on the current version instantly | Signed installer with automatic update, and a rollback that works |
| Dense keyboard data entry | Workable, rarely as fast as an operator who knows the form by muscle memory | Tab order, shortcuts and instant response designed for four hundred vouchers a day |
| Local hardware | Scales, dot-matrix printers and COM-port devices are impossible or fragile | Driven directly through vendor SDKs, serial and USB HID |
| Working with the network down | Stops, unless considerable engineering is added | Continues on local data and reconciles when the link returns |
| Reach | Any device, anywhere, including phones | The machines you install it on, normally Windows |
| Right answer for | Management, reporting, anything multi-device or remote | The counter, the shop floor, the weighing station |
How it runs
From first conversation to live.
Indicative for work of this shape. The pilot is not optional — nothing is switched over until the people using it say it holds.
- 1 week
Discovery
We watch the actual data entry and list every device that has to be driven. The device list is what makes or breaks the estimate.
- 4-7 weeks
Core build
The entry path and hardware integration first, tested against the devices on your floor rather than equivalents.
- 2 weeks
Counter pilot
One counter or one machine runs on it while the existing process continues, until the operators stop reaching for the old system.
- 1-3 weeks
Rollout
Remaining machines, signed auto-update switched on, and the sync path to the web platform verified under a deliberate network cut.
After launch
What changes.
- The operator stops waiting for the screen, which over a day is the whole argument for desktop.
- A dropped connection stops being a stopped counter.
- Hardware that was previously driven by hand, or not at all, becomes part of the record.
- Updates reach every machine without a technician visiting each one.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Is desktop software not outdated?
For most applications, yes, and we will recommend web. It stays the right answer for dense data entry, local hardware and operation without a network. Choosing desktop for those reasons is an engineering decision, not a legacy one.
Can it work with our web system too?
Yes, and it usually should. The common pattern is a desktop client at the counter or on the shop floor and a browser for management, both against the same API so the rules cannot drift apart.
What about macOS or Linux?
Possible, and worth discussing. Most of the demand for this work is Windows, because that is where the hardware drivers and the existing estate are.
How are updates handled?
Signed updates are delivered automatically and applied on restart, with the version visible in the application and a rollback path if a release misbehaves.
Can the desktop app and a web system share one database?
They should share an API rather than a database. Two clients writing directly to the same tables is how business rules drift apart; one API in front of it means the rules cannot differ between the counter and the browser.
What happens when a machine has been offline for a week?
It keeps working on local data and reconciles on reconnect, under a conflict rule chosen during discovery rather than left to whatever the code does by default. Anything genuinely ambiguous is surfaced to a person instead of being resolved silently.