When a company asks for an internal platform or a working tool, the default answer today is almost automatic: "we'll build it for the web". Often that is right. But there is a category of tools — the ones used all day, on fixed workstations, touching files and peripherals, sometimes offline — where forcing the browser adds friction that costs time every single day. In those cases a native desktop app built with Electron is the more rational choice on return. This is a decision guide: when desktop is worth it for a smaller company, when it is not, and what it really costs to maintain.
What Electron is, and why it still matters
Electron wraps a web app — HTML, CSS, JavaScript — inside a desktop application you can install on Windows, macOS and Linux, with access to the operating system. It remains the de facto standard: VS Code, Slack, Discord, Figma Desktop, Notion, 1Password and Linear all run on it. The project ships a new major roughly every eight weeks and keeps the last three current, so it is not a technology standing still. The advantage for a software house is economic before it is technical: the same stack as a web app becomes a desktop app, reusing code, skills and UI. For a smaller company that means one team and one codebase covering web and desktop, instead of two separate worlds.
Where desktop beats web and mobile
Desktop is not "better" in the abstract. It earns its place when at least one of these working patterns applies:
- Heavy, daily use. Someone who lives in the tool for six to eight hours a day gains from keyboard shortcuts, multiple windows and not depending on one browser tab among twenty others.
- File system and peripherals. Label printers, barcode readers, scanners, bulk reading and writing of local files, shared folders: the browser is caged in its sandbox here, the desktop is not.
- Fixed workstations. Back office, warehouse, reception, laboratory: always the same machines, where an installed app that updates itself is sturdier than a URL people have to remember.
- Offline work or shaky connectivity. A local database that syncs when the network returns stops the work from stopping when the line drops.
- Sensitive data that stays on site. In some contexts keeping the data on the machine, without going through an exposed server, makes the compliance conversation simpler.
Mobile is the mirror image: a phone app for short tasks, on the move, with the camera and push notifications (see what it costs to build a mobile app). If the work is sitting down and grinding through data, the phone is the wrong tool.
Electron, web app or fully native
The choice trades development cost against weight and system access. In short:
| Criterion | Web app | Electron (desktop) | Fully native (Tauri / Qt / Swift) |
|---|---|---|---|
| Initial cost | Lowest | Low, it reuses the web stack | Highest, it needs dedicated skills |
| File and peripheral access | Limited by the sandbox | Full | Full |
| Works offline | Partly | Yes | Yes |
| App size and memory | Nothing to install | Heavy: around 80–200MB, 120MB+ of RAM | Light: Tauri around 2–10MB, 30–50MB of RAM |
| Reuse of web code | Total | Nearly total | Little |
| Distribution and updates | Instant, it is a URL | Installer and auto-update to manage | Installer and auto-update to manage |
Tauri — a Rust backend with the system WebView — is the serious alternative to Electron when size and memory genuinely matter. We consider it, but it needs Rust skills and its ecosystem is less mature: for many internal platforms the difference does not justify the cost, and Electron stays the fastest route to a result.
The cost and maintenance trade-offs, unsweetened
Desktop adds cost lines a web app does not have, and they belong in the budget from the start:
- Signing and notarisation. macOS requires membership of the Apple Developer Program, around €99 a year, and notarisation is mandatory outside the Mac App Store. Windows needs a signing certificate to avoid the SmartScreen warnings. Without signing, silent auto-update does not work on macOS.
- A distribution pipeline. Installer, update channel and version management: with tools like electron-updater the infrastructure cost is low, but it has to be set up and kept running.
- Security updates. Electron embeds Chromium, so the updates have to be followed or you carry known engine vulnerabilities with you.
A real case: the NaCode Studios Tool
Our own internal platform, the NaCode Studios Tool, is exactly that: an Electron desktop app we built ourselves. We use it to manage the site's services, the blog, the price list, quotes, the roadmap and contracts. We wanted it on the desktop for concrete reasons: we work inside it all day, it generates and exports PDFs to local files, and it has to keep working when the network misbehaves. By reusing the site's web stack and the Firebase backend (see Firebase as a backend), moving it from web to desktop took little: the same base code, a few additional weeks of work [illustrative estimate, to be confirmed against your own project]. The operational gain — fewer steps, fewer tools open — pays it back day by day.
How to decide
The right question is not "desktop or web", it is "where do my users sit, and what do they need to touch". If the tool sees heavy use, on fixed workstations, in contact with files and peripherals, and has to survive going offline, an Electron desktop app is often the highest-return choice — and with Electron the jump from the web is cheap. If instead the need is access from anywhere with nothing to install, the web app wins. It is the same reasoning we apply when we help companies digitise with custom software. If you want to work out which shape — desktop, web or mobile — brings the most value to your process, we can look at the case together and tell you where it is genuinely worth investing.
