Desktop applications for businesses

The browser is fine for looking things up and for a short task. It's a bad place for local files, the shortcuts people already know by heart and a device plugged in by cable. Forcing that into a website “because it updates itself” shifts the problem onto the operator, who ends up with three windows and a USB stick.

A desktop application makes sense when the station is the workplace, not a viewer. Someone on the shop floor doesn't want to log into a portal to mark a part. They want the window that was already open, with yesterday's order still there if the power went out.

It also makes sense when the data can't leave the machine. That isn't an interface preference. It's a company or client rule. The design starts from that rule: what is computed locally, what syncs when there is a network and what never syncs.

The first day at the station has three tests: install without IT improvising, update without wiping work in progress, and open the last file. They seem obvious, and they're exactly what fails when desktop is treated like a trade-show prototype.

The installer, code signing and the update channel are part of the job, not an appendix. If the fleet is Windows only, we don't pay for the complexity of another operating system just to show an icon on a slide. If there really are macOS and Windows at the same stations, it's decided at the start and tested on both.

A bad release can be rolled back. The shift shouldn't discover the change halfway through a report. The update window is agreed with whoever runs the station, not with the calendar of whoever compiles.

The connection to the ERP, email or the network folder is drawn as a boundary: what goes out, what comes in, what happens if the other side doesn't answer. The application doesn't freeze. It says what it saved locally and what is pending. A report marked “sent” that never left is worse than a pending one, because the office believes the work is done.

The antivirus, the user without admin rights and the network folder that drops at three in the afternoon are part of the test. The installation guide names them. A “next, next, finish” PDF that never mentions the real fleet isn't a deliverable.

The code, the installer and the build process stay with the company. Another team can take over in a year without asking us for the keys. Code signing is decided with IT: who signs, where the certificate lives and how it's revoked.

The manager wants the report. The person at the station wants to stop repeating it. Those two needs are written down separately. If only the report gets designed, the station stays on paper and the report stays empty. The first use that counts is the shift's, not the dashboard's.

Whoever installs it is IT or an internal provider. They get requirements, permissions, how to roll back a release and who to notify. The application isn't “left on a desktop” waiting for someone in a hurry to copy it to a shared folder with no procedure.

If the same file later has to be viewed on mobile or on the web, we say which one is the source of truth. Duplicating the logic in three places without that sentence is how two versions of the same report appear and nobody knows which one closed the order.

We don't turn a complex spreadsheet into an application just because the spreadsheet is scary. If three people use it, the data never leaves the machine and the fear is about format rather than operations, we say so before quoting. Desktop is justified by the station, the device or the policy, not by the wish to “have a program”.

Nor do we promise it'll be cheaper than a web app because “it's only internal”. The station, the installer and testing on real machines all cost. What it saves is the operator's time and the risk of data leaving where it shouldn't.