Why this decision is hard to reverse
Choosing between a desktop application and a web application is one of the few software decisions that is genuinely expensive to change later. Almost everything else can be revisited: you can swap a database, restructure an API, redesign an interface. Moving a mature desktop application to the browser, or the reverse, usually means rebuilding the front end entirely and often reworking the data layer alongside it.
That is why the decision deserves more than a preference. In our experience it is usually made by whoever is loudest in the room, and the argument is rarely about the actual work being done. Someone says everything is web now, someone else says the last web tool was slow, and a choice gets made on impressions.
There are four questions that decide it properly. If you answer them honestly, the right platform is normally obvious by the end.
One: what happens when the network drops?
If the work happens somewhere connectivity is unreliable, a factory floor, a basement, a van, a remote site, a browser is fighting its own architecture. Offline web applications exist and can work well, but you are taking on service workers, local storage limits, sync logic and a set of failure modes that are hard to test and harder to explain to users.
A desktop application starts from the opposite assumption. A local database is the normal case and the network is an enhancement. If your users lose connectivity even weekly and the work cannot stop when they do, that pushes hard towards desktop.
If your users are always on a stable office or home network, this question is neutral and you should move on to the next one.
Two: how heavy is the data entry?
There is a category of work that involves entering or reviewing hundreds of records in a sitting. Order processing, claims handling, planning, stock reconciliation, quality inspection. The people doing it are fast, they work by keyboard, and they measure a tool by how little it gets in their way.
Desktop frameworks are still better at this. A dense grid with genuine keyboard navigation, instant local filtering and no round trip on every field is achievable in the browser but it is swimming upstream. Every web framework wants to give you a form with generous padding.
Conversely, if the typical session is a few minutes of looking something up or approving a request, the browser wins easily and the density argument does not apply.
Three: who has to install and update it?
This is where web applications earn most of their reputation. One deployment, everyone has the new version, no install, no version skew, no support call about an old build. If your users are spread across organisations you do not control, customers, dealers, partners, external contractors, the browser is close to mandatory.
Desktop deployment is not the problem it was. Modern installers, silent deployment through your existing device management, and a signed update channel make it routine on managed machines. But it does require someone to own that process. If your IT function is one person who is already stretched, factor that in.
Ask a plain question: can I name the machines this software will run on? If the answer is yes, desktop is viable. If the answer is anyone with a login, it is not.
Four: what does it need to touch?
Some software has to reach into the machine it runs on. Scanners, scales, label printers, cameras, serial devices, local file systems, or another Windows application through a plugin API. Browsers deliberately limit that access, and the workarounds, local helper services, native messaging bridges, add cost and fragility.
The plugin case is the most decisive one we see. If your requirement is to extend a piece of vendor software that only exposes a Windows extension point, the decision has already been made for you, and no amount of enthusiasm for web technology changes it.
If the software only needs to talk to your own APIs and cloud services, this question is neutral again.
The answer is often both, in sequence
Plenty of the systems we build end up as a desktop client for the heavy internal work and a web application for everyone else: managers who want a dashboard, customers who want status, staff who need occasional access from a phone. That is not indecision. It is recognising that the two groups are doing different jobs.
When that is the direction, build the shared API first and treat both clients as consumers of it. The mistake is building the desktop application with its business logic inside it, then discovering a year later that the web front end needs the same rules and they now exist in two places.
If you are weighing this up now, write down your answers to the four questions before you talk to anyone about technology. The decision is usually clear on paper, and a half-hour call is normally enough to confirm it.
If you are making this decision now, a half-hour call is usually enough to narrow it down. We will tell you what we would do and why, whether or not you hire us.
Book a free consultation