Why We Still Build Desktop Applications in 2026

A decade ago, every consulting conversation about custom software ended with "so, we'll build it as a web app." The reasons were reasonable: easier deployment, centralised updates, no platform lock-in, browsers as a universal runtime. That consensus is still the default position across most of the industry.

It's also, for a specific class of work, wrong.

Roughly a third of the systems we've shipped in the last two years are desktop applications — native installers, often Windows-first, running entirely on the user's own machine. Here's when we recommend that path, and why it keeps winning engagements.

The cases where desktop wins

Large local data. A single pavement survey generates hours of 4K video. A drafting session produces DXFs that run to tens of megabytes. A laboratory inspection produces a multi-gigabyte folder of sensor outputs. The web model — upload to a cloud bucket, process in a serverless pipeline, download results — is not a nuisance in these workflows. It's a disqualifier. The upload alone can take longer than the actual analysis.

Regulated or air-gapped environments. Government infrastructure clients, defence-adjacent consultancies, and large enterprises with strict egress policies often can't run software that phones home. The moment a procurement officer asks "what data leaves our network?", the honest answer from a SaaS vendor is usually "all of it." That's the end of the conversation.

Mission-critical tooling. A drafting program that goes down during a tender submission deadline is a commercial disaster. Browser-based equivalents add dependencies — network quality, browser version, third-party service uptime — that the client didn't have when they were working locally. Desktop eliminates those dependency vectors entirely.

Feel. Professional tools accumulate muscle memory over careers. AutoCAD users have two decades of keybindings wired into their fingers. A browser CAD replacement that "mostly" maps those keys isn't a good enough product. Desktop lets you match the interaction model with precision a browser runtime rarely permits — keyboard focus behaviour, right-click menus, file-system dialogs, multi-window workflows.

The objections that age badly

Two concerns dominate the SaaS-first argument. Both of them look weaker the longer you work in B2B software.

"Deployment is harder." Historically yes. Modern tooling — PyInstaller, auto-updaters, signed installers, NSIS — has closed most of the gap. A well-packaged desktop app installs and updates with one click, same as any Mac or Windows application the user already runs. Every client we've shipped desktop software to has received it as a single installer with a cryptographically signed license file. The "deployment is hard" objection is now mostly a reflex from people who haven't shipped desktop software recently.

"You lose telemetry." Only if you want to. Structured logs can be written locally, collected on demand, or uploaded on an explicit user action. What you give up is passive telemetry — the kind where you watch user behaviour in aggregate without asking. For enterprise and government clients, not having that is a feature, not a bug.

When desktop is wrong

For collaborative tools that depend on multiple users sharing the same live state — marketplaces, CRMs, communication platforms, multi-tenant admin consoles — desktop is a losing pattern. Central state belongs on a server. For single-user or single-team professional workflows on expensive local data, the trade-offs are the opposite way round.

The question isn't "web vs. desktop" in the abstract. It's "what is the workflow, what data does it touch, where does the user already sit?" When you ask that question honestly, roughly a third of the time the answer is desktop. That's a third of the market most SaaS-first agencies refuse to serve.

What this looks like in practice

The desktop systems we've shipped lately cover a wider range than the standard image suggests:

• A 37,000-line CAD platform built entirely in Python and Qt, replacing five separate tools for civil engineering workflows
• A production computer-vision inspection tool for pavement distress detection, running on commodity GPU hardware with offline licensing
• A native Android survey application that composites chainage, GPS, and roughness telemetry directly into the video stream through a zero-allocation GPU overlay
• A traffic-analytics desktop tool that ships reports a consultancy can hand straight to a client

None of these would be better products as browser tabs. The clients who bought them didn't ask for desktop — they asked for "a tool that actually fits my workflow." The two answers turned out to be the same.

Desktop software isn't a legacy category. It's an underserved one.