Desktop, mobile or SaaS: where should your app live?
A plain decision guide for founders choosing between a desktop app, a mobile app or SaaS: offline needs, hardware, app stores, updates, pricing, data residency and team skills.
One of the first questions we ask on a new project is where the app should live. Desktop app, mobile app or SaaS in a browser? Founders often arrive with an answer already, usually "an app" meaning a phone app, and sometimes that is right. Often it is not. The choice decides your costs for years, so it deserves a slow hour before anyone opens a design tool.
This is the guide we walk clients through. It is not a formula. It is a set of questions that tend to settle the argument, plus the trade-offs we see most often when a team picks the wrong home for its product.
Start with where the work happens
Forget platforms for a minute and describe a normal day for the person using the app. Where are they sitting? What else is open on their screen? How long do they spend in the app at once?
If the answer is "at a desk, for an hour, with files open in three other programs," you are probably looking at desktop or a web app. If it is "standing on a building site, for thirty seconds, with gloves on," that is mobile, and a big-button mobile app at that. If it is "a team of twelve people who all need to see the same records, on whatever machine they have," you are describing SaaS.
The mistake we see most is building for the founder's habits instead of the user's. A founder who lives on their phone imagines everyone else does. Then the actual users, accountants or editors or lab technicians, try to do real work on a small screen and quietly go back to their spreadsheet.
Offline, files and hardware
Some requirements push you towards native software no matter what else is true.
Offline use. A browser can cache data and even run offline with service workers, but it is fragile, storage can be evicted, and users do not trust a web page to hold their work when the Wi-Fi drops. If people need to work on a plane, in a basement or in the field, native desktop or mobile is the safer bet. We will cover the mobile side properly in offline-first on mobile.
Large files and the file system. Video, photo libraries, disk images, big datasets. Desktop apps can read and write local files at full speed and watch folders for changes. Browsers have the File System Access API in Chromium-based browsers, but support is uneven across browsers, and uploading gigabytes to a server just to process them is slow and expensive. This is why most of our own tools are desktop apps: they deal with disks, local servers and big folders.
Hardware. USB devices, serial ports, Bluetooth accessories, printers, camera control, background audio. Web APIs cover some of this in some browsers. Native code covers nearly all of it everywhere. On phones, the camera, GPS, motion sensors, NFC and push notifications all work best, or only, in a native app.
Heavy compute. Running a local model, encoding video or indexing a large drive is often cheaper on the user's own machine than on your servers. That changes your margins as well as your architecture.
Distribution, stores and review
How the app reaches people matters as much as how it is built.
Mobile apps mostly go through the App Store and Google Play. You get discovery, payments and trust, and in return you accept review and fees. Apple's standard commission is 30 percent on digital goods, with a reduced 15 percent rate for small developers and for many subscriptions, and Google's structure is similar. The rules have changed in several regions in the last two years, particularly around linking to outside payment, and they are still moving, so check the current terms for the countries you care about rather than trusting a blog post, including this one. Both stores also charge a developer fee: yearly for Apple, one-off for Google.
Review is usually quick, often within a day, but it is not in your control. A rejection the night before a launch is a real risk, and so is a policy change that affects a feature you already shipped.
Desktop gives you a choice. You can sell through the Mac App Store or Microsoft Store, or distribute directly from your own site. Direct distribution means you handle payments, licensing and updates yourself, and you still need to sign your builds: on macOS that means a Developer ID and notarization, on Windows a code signing certificate so SmartScreen does not scare people off. It is more work up front, but you keep the customer relationship and most of the revenue.
SaaS has the simplest distribution of all. You send a link. Nobody reviews your release, nobody takes a cut, and a new customer can be using the product within a minute of reading about it.
Updates, pricing and data
Update cadence. With SaaS you can ship ten times a day and every user gets the fix at once. Native apps update on the user's schedule. Many people run versions that are months old, so your backend has to keep supporting old clients, and a bad bug stays in the wild until people update. That is manageable, but plan for it from the start: version your API, and build a way to tell old clients they need to upgrade.
Pricing. Each home suggests a model. Desktop software still sells well as a one-off purchase or a licence with a year of updates, and people are often happier paying once. Mobile users expect free downloads with in-app purchases or subscriptions. SaaS is almost always a subscription, per seat or per usage, which fits because you are paying for servers every month too. You can break these patterns, but you will be explaining yourself to every customer.
Data residency and privacy. If your customers are hospitals, law firms or public bodies, the first question from their IT team will be where the data lives. With SaaS the honest answer is "on our servers, in this region," and you may need hosting in the EU or a specific country, plus the paperwork that goes with it under GDPR and similar laws. A desktop or mobile app that keeps data on the device can sidestep much of that conversation. For some buyers that is the whole sale.
Team skills and running costs
Be honest about who will maintain the thing after launch. A SaaS product needs someone on call when the database fills up at 3am. A native mobile app for both iOS and Android means two platforms, two stores and two sets of yearly OS changes, even if you share code with a cross-platform framework. A desktop app across macOS, Windows and Linux means three build pipelines, three installers and three sets of signing keys.
None of that is a reason to avoid a platform. It is a reason to count it in the budget. The build is usually the smaller cost. Keeping an app working through five years of operating system updates is where the money goes.
A pattern that works for many small teams: start with a web app, even a rough one, and find out what people actually do with it. Once you know which workflows need offline use, hardware or the phone camera, build native apps for those parts only. The native app can talk to the same backend, so the web version never has to be thrown away.
A decision table
Here is the short version we use in first calls. Read down the left, and if a row is true for your product, note where it points.
| Works fully offline | Desktop or mobile |
|---|---|
| Big local files or folders | Desktop |
| USB, serial or special hardware | Desktop |
| Camera, GPS or push on the move | Mobile |
| Used in short bursts, many times a day | Mobile |
| Many users share the same records | SaaS |
| Frequent changes, fast fixes needed | SaaS |
| Buyers ask where data is stored | Desktop or mobile, or SaaS with regional hosting |
| One-off price is the plan | Desktop |
| No clear answer yet | Web app first, native later |
Most products end up with two or three rows pointing in different directions. That is normal. A field-service product might need a mobile app for technicians and a SaaS dashboard for the office. A photo tool might be a desktop app with a small web page for sharing results. The table is there to make those splits visible early, before they turn into a rewrite.
What we would do next
If you are weighing this for your own product, write down the three most important things a user does in a normal week, and next to each one, where they are standing when they do it. That list usually picks the platform better than any feature comparison.
If you want a second opinion, we build desktop, mobile and SaaS apps for clients, and we are happy to say when the answer is "a smaller web app than you think." Our custom development page explains how we work and has a short brief form. Tell us who the users are and where they sit, and we will tell you where we think the app should live.