Desktop Application Development
Most software belongs in a browser. We will usually tell you that before we tell you anything else.
Some of it does not. Work that has to happen with no connection at all. Software that talks to a piece of hardware over a cable. Files large enough that uploading them is the slow part of the job. Processing that runs for an hour and must not stop when someone closes a tab. Environments where the browser is locked down or absent entirely.
For those we build desktop applications in Electron, with TypeScript at the core. One codebase for Windows, macOS and Linux, sharing types and logic with the web and mobile sides of the same product — which is the practical reason this is a service we offer rather than a separate specialism.
What We Build
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
Cross-platform desktop applications
One codebase, three operating systems, one team maintaining it. The same argument we make about mobile, with more force: nobody wants to fund three native desktop builds of the same tool.
-
A TypeScript core
The domain logic, the data model and the validation live in typed, platform-independent code — not scattered through the interface. That is what makes it shareable with a web client or a mobile app, and it is what makes the application testable without launching a window.
-
Local data and offline operation
A real local database rather than a cache, with the application designed to work indefinitely with no connection and reconcile cleanly when one appears. Server-side authority over conflicts, the same way we build it on mobile.
-
Hardware and peripheral integration
Serial devices, USB, printers, scanners, cameras and instruments. Where the browser’s device APIs stop, this is what you build instead.
-
Large local files
Reading, processing and writing files that are too large or too sensitive to move. Streaming rather than loading, and work pushed off the interface thread so the window stays responsive.
-
Long-running and background processing
Jobs that run for minutes or hours, survive the window being closed, report progress honestly, and can be resumed rather than restarted.
-
Operating system integration
Native menus, keyboard shortcuts that match platform conventions, file associations, drag and drop, system notifications, tray behaviour and multi-window layouts. The things that make it feel like an application rather than a website in a frame.
-
Signing, distribution and auto-update
Code signing on Windows, signing and notarisation on macOS, installers for each platform, and an update channel that works silently. This is where desktop projects most often stall, because it is unglamorous and nobody scoped it.
-
Security
Process isolation, context isolation, a restricted bridge between the interface and the system, and no direct system access from the rendering layer. Most Electron security problems come from exactly one shortcut, and we do not take it.
When Teams
Come to Us
-
The work happens where there is no connection
Field sites, vehicles, factories, aircraft, remote locations. Not a poor connection — no connection, for hours at a time.
-
It has to talk to a device
An instrument, a controller, a scanner, a machine. The software exists because the hardware does.
-
The files cannot leave the building
Too large to upload, or too sensitive to be allowed to. The processing has to happen where the data already is.
-
A web product that users want as an application
Always open, always logged in, its own window, keyboard shortcuts, offline capability. A reasonable request and often satisfiable without rewriting anything.
-
A locked-down environment
Corporate or regulated settings where installed software is permitted and a browser tool is not.
-
An Electron application someone else built
Usually one that has become slow, insecure, or impossible to update. We audit before committing to anything. See project takeover and modernisation.
Do You Have a Project Idea?
Tell us what you want to build. We come back with a rough estimate and an honest view of what it takes — including whether it should be a desktop application at all — before anyone signs anything.
How We Work
What the application has to do, where it runs, what it talks to, and whether it genuinely needs to be desktop software. The output is a scope you can price and argue with.
The TypeScript core, the local data model, the boundary between the interface and the system, and the update strategy — agreed before anything is built.
Sprints, with an installable build at the end of each one rather than a demo on someone’s machine.
Automated coverage on the core, plus manual testing on each target operating system and on the hardware where that applies.
Signing, notarisation, installers and the update channel, tested end to end before launch rather than discovered during it.
Every project includes one month of bug fixing after launch at no extra cost.
Stack
- Framework: Electron, with TypeScript in the core
- Interface: React with TypeScript
- Local data: an embedded database, with a designed schema and a migration path between versions
- Backend, where there is one: PHP with Laravel, Node.js with NestJS, Python with Django
- Sync: offline-first with server-side authority over conflicts
- Hardware: Node native modules and serial or USB libraries, per device
- Testing: Playwright for end to end, unit and integration coverage on the core
- Distribution: platform installers, code signing, macOS notarisation, automatic updates
- Delivery: CI pipelines building all three platforms, crash and error reporting
Performance and Quality
Electron has a reputation for producing heavy applications, and it is partly deserved. The usual causes are specific and avoidable: everything loaded at startup, work done on the interface thread, data held entirely in memory, and no budget anyone was measuring against.
We set numeric targets during scoping and test against them — a cold start time, a memory ceiling under realistic load, and an installer size. They go into the estimate and QA checks them before release. On a desktop tool somebody uses all day, those numbers are the difference between software people tolerate and software they rely on.
Accessibility works the same way. WCAG 2.1 AA is a line in our estimates, not an aspiration, and keyboard navigation matters more here than almost anywhere else — desktop users expect to work without reaching for a mouse.
Industries We Build For
Desktop tools turn up wherever the work is physical, regulated, or data-heavy. Construction and PropTech is where we see them most.
How We
Work Together
-
Fixed scope
A defined build, priced per module, with a timeline. Suits a clear brief. -
Ongoing team
Developers and QA working to your roadmap. Suits tools that will keep changing as the process around them does. -
Desktop alongside web or mobile
Where the same product needs more than one client, the shared TypeScript core is the reason to build them together rather than separately. See -
Support retainer
After the first month of free bug fixing runs out. Desktop applications need ongoing attention for reasons web applications do not — operating system updates, signing certificate renewals and store or distribution policy changes. SeeWe price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
It can be, and the causes are known rather than mysterious. A Chromium runtime sets a floor on installer size and memory, and that floor is acceptable for most business tools. Everything above the floor is a build decision — what loads at startup, what runs on the interface thread, how much data is held in memory at once. We set targets for those during scoping and measure against them, which is the part most Electron projects skip.
-
Electron is where our depth is, and we would rather say that than pretend to be neutral. It also shares a language and a type system with the web and mobile halves of the same product, which is a real and recurring advantage. Tauri produces smaller binaries and is a fair question to ask, particularly if installer size is a hard constraint — if that is your situation we will say so rather than talk you out of it. A fully native desktop build is right when the application depends on something only the platform can do, and that is rarer than it sounds.
-
Often not, and we will tell you during scoping rather than after you have signed. A browser is cheaper to build, cheaper to deploy and cheaper to update. Desktop earns its cost when the work is genuinely offline, talks to hardware, handles files that cannot move, or runs in an environment where a browser is not an option.
-
Often a large part of it, if it is already React and TypeScript. What does not come across for free is the part that makes it feel like a desktop application: local data, offline behaviour, OS integration and the update mechanism. We scope those as real work rather than as a wrapper.
-
Yes, including Windows code signing, macOS notarisation, installers for each platform and the automatic update channel. You will need to hold the developer accounts and the certificates, and we will tell you which ones and in what order.
-
Yes, starting with an audit. Older Electron applications often carry a security shortcut in the rendering layer and a runtime several major versions behind, and both are worth knowing about before anyone promises a timeline. See project takeover and modernisation.
-
We give you a rough estimate as soon as we understand what the application has to do. The detailed number comes after the scope is agreed, broken into modules and priced individually, so you can see what offline data, a hardware integration or the signing and update pipeline actually costs and decide what belongs in version one.