Desktop application experiments

High-level concept

I want one project that forces me out of the browser and into a real desktop workflow. The goal is to learn what changes when the UI is native, what Electron buys me, and how distribution feels when the app is shipped as a desktop product instead of a web app.

The project also gives me a place to test deployment tradeoffs. For some ideas, the better answer may be a packaged desktop app. For others, a service-style setup with docker-compose may be the cleaner path. I want to compare those options on a small enough project that I can actually finish it.

For a project like this, Architecture for small tools keeps the surface area small, complexity at the edges, and deployment boring. The project also uses the same Build over buy instinct: learn by building the thing myself.

Detailed steps

• Pick one concrete app idea that is useful enough to finish.
• Decide whether the first version should be native, Electron, or a deployment experiment.
• Build the smallest useful version with one clear workflow.
• Package the app so it can be installed or run by someone else.
• Compare the packaging, update, and maintenance costs with a docker-compose style setup.
• Write down what I would choose next time and why.

Step 1: Choose the first target

Select one app idea that is small, self-contained, and annoying to do well in the browser. Good candidates should have local state, offline use, desktop integration, or a strong reason to live outside a normal web UI.

The first target should answer one question clearly:

• What do I learn from a native app that I do not learn from a web app?
• What do I learn from Electron that I do not learn from a native app?
• When is deployment simpler because the project is a packaged app or a local service instead of a browser app?

Step 2: Build the first version

Implement the smallest version that proves the workflow. Keep the UI simple and focus on one thing working end to end.

Use that first pass to learn the parts that are easy to miss from web-only work:

• app startup and local state
• packaging and installation
• updates and versioning
• file system access or system integration
• release friction

Step 3: Test distribution and deployment

Ship the app in the simplest way that feels real. If the project is desktop-first, test how it is packaged and installed. If the project behaves more like a local service, test whether docker-compose gives a better deployment shape than a browser app plus backend split.

The point is not to create a perfect release pipeline. The point is to understand the tradeoffs well enough to stop treating web deployment as the default answer.

Step 4: Capture the comparison

Write down what changed across the options:

• development speed
• runtime complexity
• distribution friction
• maintenance cost
• user experience

Use that comparison to decide what kind of non-web project is worth building next.