Desktop apps with Electron
Some software belongs on the desktop. It has to work offline, talk to a printer or a scanner, or simply sit in the taskbar all day. Electron lets us ship one codebase to Windows, macOS and Linux. It also makes it very easy to ship an insecure app, so we set it up properly from the first commit.
01In detail
What we take care of
One codebase, three platforms
Windows, macOS and Linux builds from the same source, with native menus, tray icons and shortcuts where users expect them.
Offline-first data
Local SQLite storage that syncs with your server when a connection appears, with conflicts resolved rather than silently overwritten.
Auto-updates
Signed releases delivered in the background, with staged rollouts so a bad version can be pulled before everyone has it.
Code signing & installers
Signed and notarised builds, so Windows SmartScreen and macOS Gatekeeper do not scare your users away.
Security hardening
Context isolation on, Node integration off in the renderer, a strict content security policy and a narrow, validated IPC bridge.
Hardware & system access
Printers, scanners, serial devices and the file system, reached through small native or Python helpers when web APIs fall short.
02Process
How it runs
If a web app would do the job, we will say so. Desktop software costs more to ship and support, and it should earn that.
Define
1 week
Which platforms, which devices, what must work offline, and how updates will reach users.
Prototype
2 – 3 weeks
The riskiest part first, usually hardware access or sync, proven on real machines.
Build
2-week cycles
Installable builds every cycle, tested on Windows, macOS and Linux.
Release & support
Ongoing
Signing, update channels, crash reporting and fixes after launch.
03Deliverables
What you get
- Signed installers for each platform
- An auto-update pipeline with release channels
- Crash and error reporting
- Source code and build pipeline in your repository
Tools we reach for
- Electron
- TypeScript
- Vue
- Python
- SQLite
- electron-builder
- GitHub Actions
Security checks
Six security checks before every launch.
Before anything goes live, we test it the way an attacker would, then write down what we found and how we fixed it. The same six checks run on every project, from a one-page website to a government portal.
- 01
Scan for known weaknesses
We check your code, the libraries it uses and the server for weaknesses attackers already know how to exploit.
OWASP Top 10 · CVE database
- 02
Try to break in
Our engineers attack it the way a real attacker would: logins, permissions, file uploads, pages that should be hidden.
OWASP ASVS
- 03
Check every public link
Every public page and address is crawled for files, folders and test pages that should never have been online.
OWASP Top 10
- 04
Look for malware
The code, the server and anything users can upload are checked for malware and hidden backdoors.
Before every launch
- 05
Try to trick the AI
For AI agents, we try to make them leak data, ignore their instructions or use access they should not have.
OWASP Top 10 for LLM Applications
- 06
Write it all down
Every finding, how we fixed it and the re-test that proves it, in a report your auditors can read.
ISO/IEC 27001-aligned process
Our process follows ISO/IEC 27001 controls. Prospiral is not ISO certified. VAPT means vulnerability assessment and penetration testing: the first two checks above.
05Questions
Questions we get asked
It is larger than a fully native app. It is also what VS Code and Slack run on. For most business software, one codebase across three platforms is worth the extra megabytes.
Yes. We design the data layer offline-first and sync whenever a connection is available.
Often, yes. We add the desktop features users actually need and lock down the security settings that a plain wrapper leaves open.
Start a conversation
Tell us what’s broken.Or what you want built.
Send a few lines about the system or the idea. One of the engineers who would actually do the work will reply, usually within a working day.