Desktop software, for the jobs the browser can’t reach
Most software belongs on the web now, and we’ll usually tell you so. But a browser can’t drive a label printer, read a scale, process ten thousand files from a local folder or keep working when the connection drops. When the job needs the machine itself, you need a desktop application.
When a desktop app is genuinely right
Hardware access
Scales, scanners, label and receipt printers, serial and USB devices, cash drawers. Browsers are deliberately walled off from most of this.
Genuinely offline
A workshop, a remote site, a secure network with no internet. Not “offline mode” — actually no connection, for days.
Bulk local files
Processing thousands of files from a folder or network share, where uploading them to do the work would be the slowest part of the job.
Long-running work
Jobs that run for hours and must survive a closed laptop lid, a logout or a browser tab nobody remembered to leave open.
Existing Windows systems
Integrating with line-of-business software, a local database or a legacy desktop application that isn’t going anywhere.
Locked-down environments
Networks where an internal desktop tool is permitted and an external web service isn’t. More common than people outside those sectors expect.
When it isn’t — which is most of the time
We’d rather talk you out of a desktop app than build one you’ll regret, because the regret arrives at update time rather than at launch.
- Updates are your problem now. A web app updates once. A desktop app has to reach every machine, and the one that never updates is the one that breaks.
- Installation is a support cost on every machine, forever, including the new laptop someone got last week.
- It’s one platform. Windows only, unless you build again for Mac — and a web app would already have covered both plus tablets.
- Remote access gets awkward. Working from home means a VPN or a remote desktop, which is usually worse than a browser.
If the honest answer is a web application, we’ll say so in the first conversation and quote that instead.
What we build it in
Chosen for what the application has to do and who maintains it afterwards, not for what’s newest.
- .NET with WPF for most new Windows applications. Mature, fast, good hardware and database access, and plenty of developers who know it — which matters when we hand it over.
- WinForms when we’re extending or maintaining something that already exists in it. Rewriting a working WinForms app for the sake of modernity is rarely worth the money.
- Electron when it’s genuinely a web application that needs a desktop wrapper and local access, and your team already works in web technologies. Heavier, and we’ll say so.
Shipping it properly is part of the build: a real installer, code signing so Windows doesn’t warn your staff it’s dangerous, and automatic updates so version drift doesn’t become your support queue.
How a desktop project runs
Confirm it has to be desktop
The first question, asked properly. If a web app does the job you’ll hear that before anyone has spent anything.
Pin down the environment
Windows versions, user permissions, whether staff can install software, what the network allows, what hardware is attached. This shapes everything and is rarely in the brief.
Prove the hardware early
If it drives a device, we get that talking in week one. Hardware integration is where estimates go wrong, so it goes first rather than last.
Build, with installable versions throughout
You run it on a real machine in your real environment as it’s built, not in a demo on ours.
Signed installer and update channel
Plus documentation for whoever deploys it, so rollout isn’t a phone call to us for each machine.
Common questions
Can it work with our website or web system?
Usually the best shape for these: the desktop app handles hardware and local files, and talks to a web backend for everything shared. You get device access where you need it and one source of truth everywhere else. We build both halves.
We have an old desktop app nobody supports. Can you take it on?
Often, and it starts with reading what’s there. Sometimes it’s maintainable and the right move is to keep it running and fix the three things that hurt. Sometimes it has to be rebuilt. We’ll tell you which, with reasons, rather than defaulting to the rebuild.
Does it need to be installed on every machine?
Normally yes, though it can be deployed centrally through your existing tooling if you have it. If installing on each machine is a blocker, that’s a strong argument for a web application and worth raising early.
What about Mac?
Not from the same build, unless it’s Electron. If both platforms are needed, a web application is almost always cheaper than two desktop applications — we’d rather say that now than after you’ve paid for one.
Who owns the code?
You do, with the source and the documentation. Standard .NET, standard tooling, no private framework and nothing that depends on us still being here.
Tell us what it has to touch
The hardware, the files, the systems, and whether it works without a connection. Those four answers tell us whether this is a desktop application or a web one.