Why I Still Build Desktop Apps

I keep building Windows desktop apps. Not because I can't build SaaS — I did. But because, for what I ship, desktop is a better deal.

1. No infrastructure

With SaaS, you do not just ship features. You run a system. Servers, auth, scaling, monitoring, security — every one of those is a background process that quietly demands your attention for the rest of the product's life. A desktop app cuts all of that out. I write the feature, ship it, and move on to the next one.

2. The software does not depend on me

If I stop maintaining a web app, it degrades and eventually disappears. A desktop app keeps working. No servers to shut down, no accounts to break, no "service discontinued" email to send. The user owns a working tool, and nothing I do on my end can take it away from them. That is a different kind of contract than most software signs with its users, and I think it is the honest one.

3. I do not touch user data

I do not store files. I do not run databases with user content. I do not carry that responsibility, and the user does not have to trust me with it. Everything stays local to the machine that paid for the software. That single decision removes an entire class of problems — compliance, breaches, migrations, exports — and it simplifies the product at every layer.

4. One engine, multiple apps

After a few projects, I stopped starting from scratch. Same stack every time: .NET, WPF, SQLite, LiteDB. Same patterns, same infrastructure layer. What I build in one app shows up in the next one within weeks. That is how I have shipped several products in a short span — not by working faster, but by reusing everything I had already paid for in time.

"I have not shipped more products by working faster. I have shipped more by refusing to start over."

5. Features compound

Sometimes a feature only makes sense in one app. But once it exists, it is cheap to move. A scheduler, a sync layer, a set of UI components — they stop belonging to a single product the moment a second product needs them. Every app I ship makes the others a little better, almost for free. That is not an accident of the architecture. It is the whole point of it.

6. Desktop is not "hard" anymore

Distribution, updates, code signing — all solvable, all solved. Users install once. Updates are automatic and quiet. No installer download per version, no friction, no support tickets about "how do I get the new one". Most of the historical pain points of desktop distribution went away years ago; people just have not noticed because the conversation moved on to the browser.

7. Narrow purpose, not small codebase

"Small" is the wrong word. FTPie is around 550,000 lines, speaks ten-plus storage backends, and carries several integrated sub-apps inside it. BackupKit will land in the same weight class. What stays small is the purpose — each app has one job it refuses to drift away from. Snoq is notes on disk, encrypted, nothing else. TabChart is charts for traders who keep twenty tabs open. The complexity is real, but it is all pointed at one outcome, and that is what keeps a codebase this size shippable by one person. Saying no to adjacent features is most of the design work. A focused app can be deep; a diffused app can only be shallow.

So why not SaaS?

Because SaaS optimises for reach and for recurring revenue, and those are real things, but they are not the things I am optimising for. Desktop optimises for independence, simplicity, and longevity. I care more about that. The result is software that works without me, has near-zero ongoing cost, does not collect user data, and gets better through reuse. It is not trendy. It is stable, fast to build, and hard to kill. If you want maximum distribution, build SaaS. If you want control and durability, desktop is still underrated.