Desktop app development for work that needs the machine.

What is custom desktop application development?

It is the program someone installs on a Windows or macOS machine instead of opening in a browser tab. The tool that talks to a barcode scanner. The editor that works through a folder of large local files without uploading any of them. The screen on a shop floor that keeps working when the internet does not. Custom desktop application development means those rules, screens and data are written for one business rather than sold to many.

Most of it is Windows and macOS app development from one codebase, Electron or Tauri underneath, with a signed installer coming out for each operating system. Which of those two gets used is decided by what the app has to touch, not by which framework is more interesting to build in.

AI-assisted desktop app development is how the drafting happens here. The method is the same one behind every kind of build on this site and it has its own page, so this one stays on what is specific to the desktop: everything that has to be true after the demo works.

When does a desktop app beat a web app?

When the job needs the machine. A receipt printer, a barcode scanner, a serial device or a USB dongle. Files too large or too private to push to a server. Work that continues while the connection is out. Software that has to live in the menu bar or tray, hold a global shortcut, open a file type on double click, or run full screen on a kiosk nobody logs into. An app that controls a machine tool or a lab instrument does not get a choice.

It loses when none of that is true. If the product is screens over a database and everyone already has a browser, a web app is cheaper, updates itself without a signed package, and runs on the phone people will also want. An installable web app goes one step further and gives you its own window, a dock or taskbar icon and an offline copy, with no installer at all.

And the cheapest desktop app of all is the one that already exists. LibreOffice, GIMP, VLC, Obsidian and a shelf of quiet utilities cover the standard versions of this work well, and I will tell you to use one of them rather than pay me. What gets built is the thing your work needs that no general product has: your rules, your data, the device nobody else writes a driver for.

Should I use Electron, Tauri, an installable web app or native code?

Those are the four real options. What separates them is size, how much of the machine the app may reach, how much code it shares with your web app, and who you can hire to look after it in three years.

Which of those would you pick for me?

Start from the web app you already have and ask what it is missing. If the answer is only a window of its own and an offline copy, install it and spend nothing more. If the answer is a device, a folder of large files or a permission the browser will not grant, that is a native shell. Electron is the default when the people who inherit the app are web developers and identical behaviour on every machine is worth its size. Tauri is the better fit when a small installer and lower memory matter more than the size of the ecosystem behind the tool.

Native code earns itself in three situations: an app that lives in the menu bar and touches system services constantly, a very long-lived tool where startup time and memory are the product, and hardware the other three reach awkwardly. It costs two builds and two skill sets, so it is the option I reach for last rather than first.

One more thing gets checked before the framework is chosen: what is on the machines. Recent Electron releases need Windows 10 or newer, and Windows 10 is itself past its support end, so a fleet of old shop floor PCs can decide the question on its own. Tell me what Windows and macOS versions you actually deploy and the short list gets shorter.

What are the hard parts of shipping a desktop app?

Signing and notarisation. On macOS an app outside the App Store needs a Developer ID certificate, a hardened runtime and a notarisation pass from Apple, or your own software is the thing showing a warning on your customer's desktop. On Windows an unsigned installer says unknown publisher, and even a signed one can still draw a SmartScreen warning until Microsoft sees enough downloads and age behind the certificate. Both are schedule items to plan for, not surprises at launch.

Updates. A signed update channel, one package format per operating system, and a plan for the machines that cannot update themselves. In a company with managed desktops the real question is per-user or per-machine install, and whether your IT team pushes the package through their own tooling instead.

Permissions. macOS lets the person using the app decide about the camera, the microphone, screen recording and which folders are readable, and the app has to describe each request properly when it is built. A prompt that says nothing gets declined, and then the feature looks broken.

Security of software that lives on the customer's own machine. Anything inside the package can be read, so no keys, no tokens and no private endpoints in the bundle: the secret stays on the server and the app asks for the right to act. In Electron the interface is kept away from the machine behind an isolated bridge with the sender checked. In Tauri a capability file decides which windows may reach which system commands, and since its defaults let any window call the commands you registered yourself, tightening that list is part of the job rather than a setting you inherit.

Offline data and sync. What lives in the local database, what happens to a change that cannot be sent yet, and how two copies are reconciled when the signal comes back. A queue that drops quietly is worse than no offline mode at all, because the missing row turns up later in a report nobody trusts.

Testing on hardware that is not mine. A specific receipt printer, a scanner with an old driver, the cheapest laptop in the office, the machine with 4 GB of RAM and ten browser tabs open. Those get named in the plan, because a desktop app is judged on the worst machine it lands on.

Where does AI help and where does it not?

Desktop projects used to spend most of their hours on exactly the part agents are good at: settings pages, lists, forms, filters, the wiring between a screen and its data. That work now goes quickly, and it is the reason a first version is affordable at a fixed price.

What an agent cannot prove from a demo is the shell. Whether the notarisation ticket actually passed, whether the update manifest is signed with the right identity, whether the bridge between the interface and the machine checks who is calling, and whether an old Windows machine still opens the file: those are the parts I do, because being wrong there is not a visual bug. It is your customer seeing a warning about my name on their screen, or an app that no longer updates.

What does a desktop app cost?

It starts at $799, the same number as a web app, because most of what you are paying for is the same thing: screens, rules and data. The desktop part is the shell, the signing, the installer and the update channel, and the plan says which of those you need before the price is fixed. Small jobs start at $49.

After that it is one fixed price agreed on a free call, in writing, before any code exists. Two operating systems do not double the price, because one codebase genuinely covers both in most builds. What does move the number is hardware, offline sync and how locked down your machines are.