Web app, mobile app, or desktop: which one does your business actually need?

The question we get most often from new clients isn't "can you build this?" It's "what should I build?"

A founder runs a hospitality group. They want software to manage staff rosters, guest check-ins, and room service orders. They know they need custom software. They just don't know what kind. Web app? Mobile app? Both? Something else?

An ops director at a logistics company wants a system for drivers to log pickups and deliveries in the field. She's thinking "mobile app" because that's what makes sense intuitively. But when we dig into the details, a PWA might deliver everything she needs in half the budget.

A retail chain wants self-service ordering in their stores. They are picturing an iPad app. What they actually need is kiosk software. A completely different product category.

The form factor is not a preference. It is a design decision that follows from understanding who uses the software, where they use it, and what they need to do with it. Get it wrong and you end up rebuilding from scratch six months in.

This is the framework we use to figure it out.

Why the question is backwards

Most people come in with a form factor already in mind. "We need a mobile app." "We want to build a platform." "Can you make us a web app?"

That is usually fine. Sometimes the gut instinct is right. But when it is wrong, it is expensive to correct.

The right question is not "what should we build?" It is "who is going to use this, where, and what do they need to be able to do?"

The answers to those three questions determine the form factor. Every time.

A platform for internal staff who work at desks? Almost certainly a web app. A tool for warehouse workers scanning packages in a low-connectivity environment? Could be a native mobile app, could be a PWA, depending on what hardware they need to access. A self-service ordering kiosk in a restaurant? Neither of those. It is dedicated kiosk software running on locked hardware.

The form factor is an output of the problem definition, not an input. Start there, and the rest of the decision gets much easier.

Web apps: when they're the right call

A web app runs in a browser. No installation. No app store. No updates to push to users. If someone has a browser and internet access, they can use it.

That simplicity is genuinely powerful. Your staff can use it on a desktop at the office and on a laptop at home. Your customers can use it on any device. You ship one codebase and it runs everywhere browsers run. According to Statista, mobile devices accounted for over 62% of global website traffic in early 2025 — which means a web app that works well on mobile covers the majority of real-world usage without requiring a separate native build.

Web apps are the right choice for:

Staff tools and internal dashboards. If your users sit at a desk, the browser is where they live. A web app gives you full control over the interface without the distribution complexity of a mobile app or the installation overhead of desktop software.

Customer portals. Clients logging in to check project status, approve invoices, or access reports don't want to install an app. A well-built web app handles all of this cleanly.

SaaS products. If you're building software to sell to other businesses, start with a web app. It is the standard delivery format for B2B software for good reason: it works for everyone, requires no IT deployment, and you control the update cycle.

Multi-role platforms. When you have admins, managers, and end users all needing different views of the same data, a web app with role-based access is easier to build and maintain than separate mobile apps per role.

Cost range: $15,000-$80,000 for a custom web app. A simple CRUD tool with one or two user roles sits at the lower end. A platform with complex permissions, real-time data, third-party integrations, and multiple user types sits at the higher end.

When NOT to build a web app:

When your users will primarily access the product on their phones and need features that browsers don't support well: hardware access, offline functionality, or push notifications that actually get seen. When your product is consumer-facing and presence in the App Store or Google Play is part of your distribution strategy. When your workflow requires camera control, GPS tracking, NFC, or biometric authentication at a level that browser APIs cannot match.

Mobile apps: when they're the right call

Mobile apps are installed on a device. That distinction matters more than it sounds.

Installation creates a persistent relationship between your software and the user's phone. It also gives you hardware access that a browser can't match: GPS with continuous tracking, camera with full control, NFC, Bluetooth, biometrics, push notifications that arrive even when the app is closed, and offline functionality backed by on-device storage.

Native iOS/Android vs cross-platform. A native app is built specifically for one platform using Apple's or Google's official tools. A cross-platform app uses a framework like React Native or Flutter to write one codebase that compiles to both platforms. Cross-platform is the practical choice for most business applications. It cuts development time by 30–40% and produces apps that are indistinguishable from native for most use cases — with code reuse averaging 70–90% across iOS and Android, leaving only 10–30% for platform-specific work. Pure native is worth the extra cost for apps with very demanding graphics performance, deep platform-specific integrations, or where a single-platform experience matters (like an Apple Watch companion app).

Mobile apps are the right choice for:

Field workers. Technicians, delivery drivers, inspectors, healthcare workers in the field. Anyone who uses software while moving. They need reliable offline access, GPS, and camera. Mobile is the only platform that delivers all of that.

Consumer-facing products. If you're building a product for the public, the App Store and Google Play are how you reach them. App store presence is a distribution channel, a trust signal, and a discovery mechanism. You cannot replicate that with a web app.

Products where push notifications are central. Reminders, alerts, order updates, appointment confirmations. Push notifications significantly outperform email for time-sensitive delivery: according to MoEngage and industry benchmark data, push notifications average a 20% open rate compared to under 2% for email, with click-through rates of up to 28% versus 1–2% for email campaigns. If notification delivery is core to your product's value, mobile earns its cost.

Hardware-dependent workflows. Anything that needs to scan QR codes or barcodes, photograph documents, capture GPS coordinates, or interact with Bluetooth devices. Browser-based camera and GPS work well enough for simple cases, but for production-grade use in a business workflow, native mobile API access is more reliable.

Cost range: $25,000-$150,000 for a properly built mobile app. A focused single-feature app on one platform sits at the low end. A two-platform cross-platform app with offline sync, push notifications, and third-party integrations sits in the $60,000-$120,000 range. A fully native app for both iOS and Android with complex logic runs higher.

When NOT to build a mobile app:

When the task is suited to a larger screen. Data entry, complex forms, dashboards with multiple data panels, and anything requiring side-by-side comparison are better on a desktop or laptop. Forcing these into a mobile app produces a frustrating experience. When your users are office-based and have no business reason to be on a phone. When budget is tight and the use case can be met with a PWA.

Desktop applications: the underrated option

Desktop software gets overlooked. Founders and ops leaders default to "web app" for internal tools because web apps are familiar. But for a specific set of use cases, desktop is the right answer and often the cheaper long-term choice.

A desktop application installs on a Windows or macOS computer. It has full access to the file system, local hardware, and system resources. It can run without internet. It can process large files, run background tasks, and perform computations that would be slow or impossible in a browser.

Desktop apps are the right choice for:

Heavy data processing. Video editing, audio production, large-scale data analysis, CAD, and engineering tools. These tasks require direct access to CPU and GPU resources that a browser cannot provide at full performance.

Offline-first professional tools. Accounting software that must work at a client site with no internet. Legal document tools that must not send data to a server. Internal configuration tools for hardware devices.

Enterprise operational tools. Many enterprise businesses run critical workflows on desktop software that integrates with local hardware (label printers, barcode scanners, card readers) or legacy systems that have no API.

Secure, air-gapped environments. Government, defense, financial services. Situations where data must not leave the machine.

Technologies: Electron lets you build a desktop app using web technologies (HTML, CSS, JavaScript), which means you can share code with an existing web app. .NET (Windows) and Swift/AppKit (macOS) give you full native performance if that matters. Most business desktop apps built today use Electron because the cost savings from shared code outweigh the performance overhead.

The often-overlooked insight: if you already have a web app and realize you need a desktop version, Electron can get you there without starting from scratch. The incremental cost is far lower than building a new native app.

Kiosk software: a specific business case

Kiosk software is not a web app that runs on a touchscreen. It is a purpose-built application running on locked hardware. No task bar, no ability to switch windows, no access to the rest of the operating system.

The hardware and the software are designed as a system. The user taps a screen in front of them and interacts with one interface. They cannot close it, minimize it, or navigate away. That constraint is the point.

Who needs kiosk software:

Retail: self-checkout, product catalog browsing, loyalty enrollment.

Hospitality: hotel check-in and check-out, room service ordering, restaurant self-ordering and payment.

Healthcare: patient check-in, appointment confirmation, intake forms.

Events: ticket validation, badge printing, registration confirmation.

What makes kiosk software different from a standard app:

It runs in a locked mode (called kiosk mode on most operating systems). The interface is designed for finger-touch on a large touchscreen. It handles intermittent failures gracefully. If the payment terminal disconnects, the software recovers cleanly and shows the user an appropriate message rather than crashing. It needs to be remotely managed across many physical devices.

If you need kiosk software, do not try to build a web app and display it in a browser in fullscreen mode. It will break. Use dedicated kiosk software development from the start.

TV/OTT apps: for media and content businesses

TV apps run on smart TVs and streaming devices: Apple TV, Roku, Amazon Fire TV, Samsung Tizen, and LG webOS. OTT (over-the-top) refers to delivering video content directly over the internet, bypassing traditional broadcast.

Most businesses do not need a TV app. But a specific set of them do.

Hospitality: In-room entertainment systems for hotels. Guests control the TV from an app that knows their preferences, can order room service, or book a spa appointment from their room's TV.

Video streaming products: If you are building a subscription streaming service or a content platform with a library of video content, TV apps are table stakes. Netflix, Disney+, and every streaming product in between ships on all major TV platforms.

Digital signage: Managed content displayed on screens in retail stores, lobbies, restaurants, and event venues. A TV app running on commercial-grade Samsung or LG displays gives you remote content management, scheduling, and playback.

The reality of TV app development: Every platform has its own SDK and review process. Apple TV (tvOS) uses Swift. Roku uses its own BrightScript language. Fire TV runs on Android TV. Samsung Tizen uses web technologies. Building for all platforms is expensive. Most businesses start with one or two platforms based on where their audience is.

Progressive Web Apps: the hybrid option

A Progressive Web App (PWA) is a web app built with specific technologies that let it behave more like a native mobile app.

It can be installed to a phone's home screen directly from a browser, with no app store required. It can work offline using cached data. It can send push notifications. It loads fast because assets are cached locally. On Android, PWAs are nearly indistinguishable from native apps. On iOS, they are close but with some limitations Apple has imposed.

PWAs work well for:

Internal business tools accessed primarily on mobile. Warehouse inventory apps, field service logging, inspection checklists. If the workflow is defined and the data can be cached for offline use, a PWA often matches a native mobile app for a fraction of the cost.

Extending an existing web app to mobile without rebuilding it. If you have a web app and want to make it installable and offline-capable, progressive enhancement is faster than building a native mobile app from scratch.

Consumer-facing products where app store presence is not critical and the use case doesn't need deep hardware access.

Limitations versus true native:

PWAs cannot access all device APIs. Bluetooth, NFC, advanced camera controls, and background location tracking are limited or unavailable depending on the platform and browser. On iOS, PWAs cannot receive push notifications in the same way as native apps (this has partially changed in recent iOS versions, but restrictions remain). PWAs cannot be listed in the App Store with the same prominence as native apps. They appear in search results but look like websites, not apps.

If hardware access and app store distribution are important to your product, PWAs are not a substitute for native mobile. If those constraints don't apply, a PWA can save you $10,000–$50,000 in development cost for the same functional outcome. Google's documented PWA case studies show consistent business impact: Twitter's PWA drove a 65% increase in pages per session and 75% more tweets sent, while Goibibo saw a 60% increase in conversions — all without a full native rebuild.

The decision framework

Before you commit to a form factor, answer these six questions. The answers will narrow the options quickly.

Question 1: Who uses it and where are they when they use it?

At a desk, on a computer: web app or desktop. On the move, on a phone: mobile app or PWA. In front of a fixed screen in a physical space: kiosk or TV app.

Question 2: Does it need to work without internet?

If yes, you need either a desktop app, a native mobile app with offline sync, a PWA, or kiosk software with local data. A standard web app requires internet.

Question 3: Does it need hardware access?

Camera control, GPS tracking, Bluetooth, NFC, biometrics: native mobile app. Basic camera and location: a web app or PWA with browser APIs may be sufficient. Peripheral devices (label printers, barcode scanners, card readers): desktop or kiosk.

Question 4: Is it customer-facing or internal?

Customer-facing products benefit from app store presence. Internal tools generally don't need it. If app store distribution matters to your growth, native mobile. If it doesn't, web app or PWA.

Question 5: What's the budget and timeline?

Lower budget: web app or PWA first, expand later. Need to move fast: web app has the shortest path to production. Need both web and mobile: cross-platform mobile (React Native / Flutter) shares 70-80% of the codebase and costs less than building two separate native apps.

Question 6: Is there a customer-facing and a staff-facing component?

This is the most common case we see: a business needs both a customer-facing mobile app and an internal web dashboard. The customer orders, books, or engages through the mobile app. Staff manage orders, view analytics, and configure the system through a web app. These are two products with shared logic. Budget for both from the start. Trying to shoehorn staff tools into a mobile app or customer flows into a desktop dashboard usually ends in a compromise that satisfies neither user type.

Form factor comparison

Build times assume a dedicated team. They do not include the time spent on scoping, design, and QA before code is shipped to production.

What we actually do at RaftLabs

We do not ask clients to come in with a form factor decision already made. We figure it out together as part of the scoping process.

The first conversation is about the problem. Who has it? What are they doing now? What breaks down? Where does the manual work accumulate? What is the cost of that in time or money?

From those answers, the form factor usually becomes obvious. Not always obvious on the first call. Sometimes we need to map a workflow in detail before it becomes clear that a web app with PWA features covers 90% of the need, and a native mobile app would be overkill.

We have shipped web apps, native iOS apps, Android apps, cross-platform React Native and Flutter apps, kiosk software, Apple TV and Roku streaming products, desktop apps, and hybrids of more than one form factor. We have also talked clients out of the form factor they came in with when the problem didn't fit it.

Sometimes the answer is two form factors. A loyalty platform needs a mobile app for customers and a web dashboard for ops. A restaurant chain needs kiosk software for tableside ordering and a web portal for the franchise owner to see sales data across locations. A field service company needs a mobile app for technicians and a desktop app for dispatchers processing large job files.

The starting point is always the same: what is the problem, and who is trying to solve it?

If you're still deciding what to build, that conversation is exactly where we start. We map the problem first, then figure out what form factor makes sense. No pitch before the diagnosis. Talk to us about your project.