Script or command-line tool
Your own problem; you are the only user
$0 · Minimal
△ Someone else wants to use it and cannot open a terminal
Drawing set · L0–L3
ship desktop software
Desktop software gets what web pages never get: the file system, system audio, the GPU, always-on background work. The price is that you now ship a program onto machines you have never seen, past security warnings you did not write. This drawing set maps the shapes a desktop program can take and what each level of seriousness adds.
Design philosophy
Desktop software is a program that lives on someone else's machine for years. It is trusted with their files and their system; it has to earn that and keep earning it.
Solve one problem you have
The best desktop tools start as a fix for their author's own daily annoyance. A real problem gives you a real test case every single day.
Respect the machine
Idle means idle: no hidden CPU, no background downloads, no files outside the places you said you would write. Users notice fans spinning.
Shipping is part of the product
An installer that fails, a warning that scares, an update that never arrives — these are bugs in the product, not chores around it.
Solving your own problem? Start with a script, then a small window around it. Only invest in installers, signing and auto-update once strangers need to run it.
SheetL0
Script
Used byOnly you
Per month$0
①Why move up
You have an annoyance you hit every day and want to know whether a program can remove it. The only user is you, so a terminal is a perfectly good interface.
②Architecture
One script, run by hand or at login. It reads and writes files in one known folder and prints what it did. No window, no installer.
Δ New at this level
- + A script that solves one problem
- + A known folder for its files
Shapes on the map: Script or command-line tool
③Tools
Use the language with the best library for the hard part — audio, files, images — not the one with the prettiest UI framework. The UI can come later; the core cannot be faked.
④Code and tests
- Keep a small set of real inputs from your daily use and rerun the script on them after each change.
- Log what the script did to a file you can read after something goes wrong.
SheetL1
Real users
Used byOther people, on their own machines
Per month$0–10
①Why move up
Someone else wants your tool and cannot or will not open a terminal. Their machine has different settings, a different language and none of your libraries.
②Architecture
The script gains a window and is packaged together with its runtime into something that installs with a double click. Settings move to the operating system's standard per-user folder, and the program asks for system permissions only when a feature needs them.
Δ New at this level
- + A graphical window
- + An installer that bundles the runtime
- + Settings in the OS's user folder
- + A downloadable release page
Shapes on the map: Native UI toolkit (Qt, WPF, SwiftUI) · Web UI in a desktop shell (Tauri, Electron)
③Tools
Pick the UI approach by what the core needs: native toolkits for audio, latency and small memory; a web shell when the interface is the product. Test the packaged build, not the development run — they fail differently.
Also worth knowing — not verified by this site
④Code and tests
- Install the packaged build on a clean machine or virtual machine that has never seen your code.
- Test with a non-English system language and a user name containing spaces or non-ASCII characters.
- Check memory and CPU when idle; background tools are judged by their silence.
SheetL2
Money and data
Used byPeople who paid, or trust it with their files
Per month$10–50
①Why move up
The software is sold, or it handles recordings, documents or accounts. Unsigned builds now cost you sales at the security warning, and a crash that loses a user's file costs you their trust.
②Architecture
Builds are code-signed in CI with a certificate kept outside the repository. A small online service checks licenses and serves the update feed; the program keeps working offline for a grace period. Crash reports leave the machine only with consent and without file contents.
Δ New at this level
- + Code signing in CI
- + A license and update service
- + Opt-in crash reports without personal data
- + Automatic recovery of unsaved work
Shapes on the map: Desktop app + online service
③Tools
The signing certificate is the most valuable file you own at this level: keep it out of the repository and out of any log. Never let the license check lock a paying user out when your server is down.
Also worth knowing — not verified by this site
④Code and tests
- Write files atomically — save to a temporary file and rename — so a crash never leaves a half-written document.
- Test the program with the network cut; licensing must degrade gracefully.
- Scrub file paths, user names and document contents from crash reports before they are sent.
SheetL3
Scale
Used byMany machines, several operating systems
Per month$50–500+
①Why move up
Thousands of installs run different versions on Windows, macOS and perhaps Linux, on both Intel and ARM. A bad update now breaks many machines at once, and some of them belong to companies.
②Architecture
Every release is built and signed for each operating system and chip architecture by CI. Updates go out through channels — beta, then a percentage of stable — and a bad version can be pulled from the feed so machines stop receiving it.
Δ New at this level
- + A build matrix across OS and chip
- + Beta and staged stable channels
- + Update rollback from the feed
- + Silent install for company deployment
Shapes on the map: Desktop app + online service · Web UI in a desktop shell (Tauri, Electron)
③Tools
Automate everything about building and signing; at this level a manual release step is a release that will one day be skipped.
④Code and tests
- Run the test suite on every OS and chip combination you ship.
- Release to a beta channel first and watch crash rates before the stable rollout.
- Keep the previous version downloadable so users can roll back on their own.
The architecture map
Every shape this can take. Most exist so you know what not to build yet.
Native UI toolkit (Qt, WPF, SwiftUI)
Deep system access, low latency, small memory — Subtitle-Windows' shape
$0 (check toolkit license) · Mid
△ You need the same app on several operating systems with one team
Web UI in a desktop shell (Tauri, Electron)
Cross-platform from one web codebase; UI-heavy apps
$0 · Low–mid
△ Memory use or startup time becomes a complaint, or you need system APIs the shell does not expose
Desktop app + online service
Licenses, sync, accounts or cloud processing
$5–100/mo + signing certificate · Mid–high
△ Thousands of installs across versions — you need staged update channels
Concepts you'll actually need
One plain sentence and one metaphor each. Click any tool module for the same treatment.
- Code signing
- A certificate proves who built the program; unsigned programs trigger scary warnings or are blocked outright.
- ≈ A sealed envelope with a return address, versus a package left unmarked on the doorstep.
- Installer and packaging
- Bundling your program, its runtime and its libraries so it runs on a machine that has none of your development tools.
- ≈ Shipping flat-pack furniture with every screw and the tool included.
- Auto-update
- The program checks for new versions and replaces itself, so fixes reach users who never visit your website again.
- ≈ A magazine subscription instead of hoping readers return to the newsstand.
- OS privacy permissions
- Microphone, screen recording and file access increasingly require the user's explicit consent through the operating system.
- ≈ The building's security desk, which asks residents before letting anyone into their flat.