Mobile app versus mobile web for sales teams.

A founder asked us in late 2025 to quote a native Android app for his sales team of fourteen field reps. The request came from a recent meeting where a competitor's team had been seen using a slick app on a customer visit. We asked five questions before quoting. What is the field connectivity. How much data does the rep need offline. What hardware does the rep already carry. What is the camera-and-GPS usage in the workflow. What is the budget for ongoing maintenance. The answers, taken together, pointed to a progressive web app, not a native app, and to a build cost roughly forty percent of what the founder had been mentally budgeting.

This essay is the framework behind that answer. When the native cost is justified, when a PWA does the job, and the real numbers on the build and maintenance differential.

What a native app actually costs

A native Android app for a sales team, built to a professional standard with offline data sync, role-based access, and the operational features a working team needs, costs in the range of twelve to twenty lakh rupees for the first version. iOS, if required, adds another eight to twelve lakh. The two-platform build sits comfortably between twenty and thirty-two lakh.

The ongoing maintenance is the part founders consistently underestimate. Native apps need updates against OS version changes (Android releases yearly, often with API changes that affect working features), against device fragmentation (a feature that works on one phone breaks on another), against Play Store policy changes, and against the firm's own evolving operational needs. The annual maintenance budget runs four to seven lakh per platform, and that figure is durable: it does not drop after the first year because the OS releases do not stop.

A progressive web app delivering equivalent functionality (cached offline data, push notifications, home-screen install, camera access, location access) costs five to eight lakh for the first version. Maintenance runs one to two lakh annually, because the update path is the web's update path: deploy once, every user gets the new version on the next reload.

The headline ratio is two to three times the build cost and four to five times the maintenance cost for native versus PWA. Across a three-year horizon, the difference for a single-platform deployment is on the order of fifteen to twenty-five lakh. For a two-platform deployment, the gap doubles.

When native is the right answer

Despite the cost gap, there are workflows where native is the correct choice. The list is short and specific.

The first is heavy offline-first usage with large data sets. A sales rep working in a region with consistently poor connectivity, who needs to carry the full customer record, inventory snapshot, and pricing table on the device, and update them locally for hours before the device sees the network again. Modern PWAs can do offline caching, but the storage limits and the sync reliability, at large data volumes, are weaker than native. If the offline workload is tens of megabytes of structured data with frequent local writes, native wins.

The second is hardware-intensive features. Continuous GPS tracking of the rep's location during the visit. Camera capture with custom processing (barcode scanning, document recognition, OCR of vehicle numbers). Bluetooth communication with shop-floor scanners. Each of these is possible in a PWA on Android, with limitations, and impossible or unreliable on iOS PWAs because of Apple's web platform restrictions. If the workflow depends on any of these, the native build is justified.

The third is performance-critical interactions where a fraction of a second matters. A retail floor app where the rep scans hundreds of items in a session, with each scan requiring sub-second feedback. A PWA can usually do this; the consistency at scale is where native wins.

The fourth, less discussed, is the brand and trust signal of a native app in some customer-facing contexts. This is the weakest justification on its own and rarely worth the build cost, but it is a real factor in certain market segments.

If none of these four apply, the answer is almost always a PWA.

What the PWA does well

The progressive web app, built carefully against modern web standards, delivers most of what a field sales team needs. Home screen install, so the rep launches it like an app. Offline access to data the rep cached recently, so a customer visit in a building with no signal still has the customer record available. Push notifications, so the rep gets alerts on new orders, follow-up reminders, and customer messages. Camera access, for capturing proof of visit or scanning the occasional document. Location, for geo-tagging visit logs. Touch-friendly interfaces, indistinguishable from a native app to a user who is not looking for the difference.

For Carbiforce, Metaldur, and Kawacut, the field sales workflow runs on a native Android app, because the offline-first requirement and the on-device data shape (full catalogue, brand-isolated pricing, customer history per brand) justified the native build. The decision to go native was made after the workflow was specified, not before. The reasoning was documented. The cost was understood and accepted.

For AKSD, the sales team's day-to-day operates against the same operational system the office team uses, accessed through a responsive web interface that works on phones and tablets. The reps are not doing heavy offline work. They are not scanning barcodes. They are checking customer history, confirming inventory, generating proformas. The PWA approach was the right one and continues to be.

The decision the founder should run before quoting

Before quoting any mobile app project, the five-question diagnostic that determined our answer above. What is the realistic field connectivity, measured (not assumed). How much data does the rep need offline, in megabytes and in update frequency. What hardware features (camera processing, GPS, Bluetooth, NFC) are part of the workflow, not optional. What is the annual maintenance budget the firm has allocated, separately from the build budget. What is the team's appetite for app store release cycles and review delays.

The answers point to native or to PWA with very little ambiguity. Native rarely wins on more than one or two of the five. PWA typically wins on three or four. The founders who choose native without running the diagnostic are usually the founders who later ask whether the maintenance cost can be reduced. It cannot, materially, without changing the architecture.

The longer treatment of the broader build-versus-buy question is in the SaaS cost essay. The architectural pattern that supports either choice cleanly, without committing the firm to a path too early, is described in the decision infrastructure essay.

The middle path most firms do not consider

The pattern we recommend, increasingly, is to build the PWA first. Validate the workflow with the team. Run it for six months. If specific features emerge that demand native (a scanner workflow that the PWA cannot match, an offline scenario the PWA cannot serve), build a native shell that wraps the PWA's core and adds the specific native features needed. The firm has spent five to eight lakh on the PWA, gained the operational benefit immediately, and now spends a bounded additional amount only on the native capability that is justified.

This approach saves most firms ten to fifteen lakh against a native-first build, and reduces the risk of building features the field team will not use.

The work we do under the internal systems practice frames the mobile decision against the operational workflow, not against the device. The device follows the workflow. The workflow is what the system is for.

If your firm is within sixty days of committing to a mobile build and the five-question diagnostic raises any uncertainty, Start a Conversation.