Start with the task
“It all runs in the cloud” sounds modern. “It stays on our computer” sounds controllable. Both statements may be true. Both can also leave important questions unanswered.
Before choosing or developing an application, I want to understand what it needs to do. Must several people work simultaneously? Does it need a particular local device? Must work continue without an internet connection?
Only then does discussing the appropriate technical form become useful.
Desktop, web and cloud are not three separate boxes
A desktop application is used through an installed program. A web application is delivered using web technologies and is typically used in a browser. Cloud primarily describes how and where services are operated.
An installed program can therefore depend on a cloud connection. A web application can run on an organisation's own server. An application can also combine local and central functions.
That makes “desktop or cloud” an imprecise comparison. I would separately consider where the interface runs, where information is processed and which functions remain available without connectivity.
Start with the device, not the sales claim
Consider a fictional measurement application that regularly reads a particular device and processes local files. I would first establish the drivers, permissions and interfaces it actually needs.
A locally installed application may be appropriate. That does not mean every desktop program automatically supports every device or works without the internet. Licensing, sign-in or external services may still require connectivity.
A shared order overview across several sites raises different questions. How are changes combined? Which permissions are required? What happens during simultaneous editing? The challenge is shared information processing, not simply installation.
Offline operation is a specific capability
During a demonstration, I would ask more than whether software is “offline-capable”. I want to know which task can actually be completed without a connection.
Can an existing order be read? Can a new record be created? Are photographs retained? Is it clear which changes have not yet been transferred?
MDN explains how Progressive Web Apps can use service workers and cached resources to support offline functions. The appropriate caching strategy depends on the application, and cached information may be outdated. A web interface alone therefore provides no automatic offline guarantee. [1]
Testing should also cover reconnecting. If two people changed the same record, the application needs an understandable way to handle that situation. Silently overwriting one person's work would not be a sensible answer.
Who takes responsibility for operation?
Centrally delivered software allows some tasks to be organised centrally. Someone still needs to decide who updates it, manages access and responds to incidents.
Locally installed applications add issues such as distribution and differing workstation states. Web applications need consideration of supported browsers and required capabilities. Externally operated services require examination of agreed services and responsibilities.
No option removes all of this work. Each distributes it differently. I would compare not only the initial price but also setup, ongoing support and necessary adaptations.
You cannot judge data protection from the interface
A program window does not reveal where information is transmitted. A browser interface does not establish whether the service runs on an organisation's own server or an external provider's infrastructure.
I would ask for the actual data flows: What leaves the device? Which external services are involved? Who can access the information? What is temporarily stored on a workstation?
“Local” is not a blanket data protection approval. “Cloud” is not a blanket prohibition either. Whether specific processing is lawful and sufficiently protected needs a separate assessment.
Do not build larger than necessary
Microsoft's Azure Architecture Center describes different architecture styles with their own suitability criteria and trade-offs. Splitting software into microservices, for example, introduces additional complexity in data consistency and operation. [2]
To me, that is a useful reminder to stay with the actual requirement. A modest internal application does not automatically need a large distributed platform. Equally, scattering shared business processes across individual computers merely because the first installation is convenient would be unwise.
I would test a representative workflow as a prototype, on the intended devices, with the necessary permissions and realistic connectivity conditions. An attractive screen is a start, not a reliable selection decision.
My conclusion: The right solution helps people complete the task
The best technical form does not follow from a fashionable term. It follows from workflows, device requirements, collaboration and the operating responsibilities an organisation can reliably fulfil.
I would not judge software by how modern it sounds. I want to know whether it fits everyday work, including a lost connection or an important task outside the usual case.
Sources and context
Research checked on 11 October 2026. General technical guidance, not a specific product recommendation, cost calculation or legal approval of data processing. The application examples are fictional. Selection criteria are editorial recommendations, not guaranteed features of a particular product.
[1] MDN Web Docs: Offline and background operation
Read source ↗
[2] Microsoft Learn: Architecture styles
Read source ↗