Most desktop software gets built by teams that treat it as a web app with a wrapper around it. That's how you end up with a 300MB installer, an auto-updater nobody tested, and a UI thread that freezes every time the app touches disk. We build desktop applications the way the platform actually demands — separate processes, typed communication between them, and a release pipeline that survives contact with three different operating systems.
Why Entalogics for desktop
We've taken over enough half-finished desktop projects to know the pattern. It's rarely the framework. It's four decisions nobody made on purpose.
An unoptimized Electron build sits at 150-300MB of RAM doing nothing. A comparable Tauri build sits at 30-50MB. That gap isn't magic — it's the difference between shipping a full Chromium instance per window and not. We decide the memory budget before we pick the framework, then hold the line on it: windows load lazily, IPC calls get batched instead of chattering, and anything CPU-heavy comes off the main thread before it ships.
This is the single most common desktop bug pattern we see: someone puts a database call in the renderer because it was convenient that afternoon, and eighteen months later nobody can trace where state actually lives. We enforce the split from day one. Renderer draws pixels. Main process owns business logic, file access, and native calls. Everything crossing that boundary is typed, so a mismatch fails at compile time instead of showing up as a support ticket.
Desktop users open your app expecting it to work on a plane, in a basement server room, or during an ISP outage. If your data layer was designed assuming a live connection, it will fail exactly when the user needs it most. We build local-first with SQLite as the source of truth, sync as an enhancement layered on top — not the other way around.
It's common to see a codebase with perfect TypeScript in the renderer and completely untyped IPC calls connecting it to the backend. That boundary is exactly where bugs hide, because nothing catches a mismatched payload until a user triggers it in production. We type the IPC contract the same way we type everything else — Zod-validated, checked at build time, not discovered at 2am.
When desktop, when not
We say this on almost every first call, because it's true more often than people expect. Here's the actual test we use.
BUILD A DESKTOP APP WHEN
PICK ELECTRON WHEN
PICK TAURI WHEN
WE SAY NO WHEN
What we build on desktop
Six ways this work actually shows up for clients. Each one ends with something signed, updating automatically, and running in production on real machines.
A new desktop product, built from the architecture up. We settle the process boundary, the state model, and the update strategy before any feature work starts — because retrofitting those decisions later is where most desktop projects go sideways.
Windows, macOS, and Linux from one codebase, released on the same cadence. We've seen too many "cross-platform" apps where Linux quietly falls three versions behind because nobody's testing it — we build the CI pipeline so that can't happen by accident.
An old WinForms or Java Swing app that still runs the business but hasn't been touched architecturally in a decade. We rebuild it on a modern stack without touching the business logic that actually works, moving screen by screen so the current version stays in production the whole time.
For teams running Electron in production who've hit a wall on bundle size, memory, or startup time. We move the IPC layer, rewrite the Node backend in Rust, and port native modules to Tauri plugins — typically taking a 150MB app down under 15MB without a feature freeze.
A design pass built around how desktop software actually behaves — multiple windows, a system tray, keyboard-first workflows — instead of a responsive web layout dropped into a frame and called done.
The part most vendors quietly drop after launch. Update pipelines drift, dependencies age out, memory creeps up release over release if nobody's watching. We keep watching.
The playbook
Not experimental — these are the decisions that show up on nearly every project we take on, because they're the ones that matter.
P01
Zod schemas validate every message crossing between main and renderer. An untyped `ipcRenderer.send` doesn't survive review — it gets flagged before merge, not found in a crash report.
P02
Signed builds, delta updates, and a rollback path if a release goes bad. This runs through CI on every release, so "the updater silently broke for 20% of users" isn't a sentence we say twice.
P03
macOS notarization, Windows Authenticode, Linux AppImage signing — one CI job, not three manual steps someone has to remember on release day.
P04
better-sqlite3 for Electron, Tauri's SQL plugin for Tauri. The app is fully functional offline; sync happens when the network shows up, and conflict resolution is decided before launch, not after the first support ticket about lost data.
P05
Context Bridge in Electron, a command allowlist in Tauri. No Node access from the frontend, no arbitrary shell calls reachable from a compromised renderer. Small attack surface by construction.
P06
Settings panels, detached views, secondary windows — each one releases memory on close and syncs state through IPC instead of a global object nobody remembers writing.
Signature case
A B2B database GUI on Electron — 180MB bundle, 340MB memory at idle, 6-second cold start on Windows, and auto-update that failed silently for 20% of users. Migrated to Tauri 2 with Rust backend in 9 weeks. Bundle dropped to 12MB. Memory to 45MB. Auto-update now works for everyone.
Before
Electron · 180MB bundle · 340MB idle memory · 6s cold start · auto-update 80% success
After
Tauri 2 · 12MB bundle · 45MB idle memory · 1.2s cold start · auto-update 100% success
Industries we serve
A few sectors keep coming back to us for the same reason — a browser tab can't offer what their workflow actually needs.
Engagement shape
Not a waterfall plan that reveals problems in week nine. Testers see signed builds from week two onward.
Two senior engineers go through the codebase or the spec — bundle size, memory profile, IPC architecture, update pipeline. You get a ranked plan with real numbers attached, not a list of concerns.
The framework choice gets locked in, IPC gets typed, code-signing gets wired into CI, and one real window ships end-to-end. You're holding a signed build on all three platforms by the end of week three.
Each additional window or feature goes out behind a flag, with a signed beta release every week. Nothing waits for a big-bang release at the end.
Signed production builds for Windows, macOS, and Linux. Auto-update confirmed working in the wild, not just in a test environment. You get the runbook, or we stay on for ongoing maintenance.
Stack
Our default desktop development stack — picked for production, not quick-start templates.
Engagement
No hourly billing for time spent thinking. Every arrangement below is either a fixed quote or a transparent monthly rate.
A fixed scope, a fixed price, and a team with no juniors rotating through client work. RFC to signed release across all three platforms, typically 8-14 weeks.
FIXED SCOPE
Senior Electron or Tauri engineers who join your Slack and your standups like they're part of the team, because for the length of the engagement, they are. Scale up, pause, or step away with 30 days' notice.
PER ENGINEER
For teams that need a standing desktop architecture partner, not a one-off project — covering migration planning, update infrastructure, and hiring support across quarters.
PROCUREMENT-FRIENDLY
Founder-direct
Thirty minutes with the founder gets you a senior desktop engineer in the room, the playbook that's relevant to your case, and an honest read on whether desktop is even the right call — some of these conversations end with us recommending a PWA instead.
