Start by Asking Whether You Actually Need an App
"Let's build an app" is one of the most common requests to come out of a planning meeting. Yet a large share of the projects we consult on turn out to need nothing more than a mobile-optimized website. If the goal is to let people view your service comfortably on a phone, or to let customers submit a form from their device, responsive web is the right answer.
The signals that genuinely call for an app are fairly clear:
Whether the app is internal or customer-facing changes the calculation entirely. For a field inspection tool used by 200 employees, you can distribute through MDM or enterprise channels without store review, which frees you to use native capabilities aggressively. For a customer-facing app, install conversion is the first number to check. For typical commerce and service apps, the share of web visitors who install is often in the single digits, and median 30-day retention after install lands in the single digits too — roughly 3–6% for commerce, with anything above 10% counting as strong. Pushing users you could already reach on the web behind an install prompt is a real cost.
What Actually Separates the Three Options
Responsive Web / PWA
No store review means changes ship the moment you deploy. Being able to push an urgent fix the same day matters more than teams expect. You get home screen installation, service worker offline caching, and web push. The constraints are real, though: web push on iOS only works when the site has been added to the home screen, and Bluetooth, NFC, and background location tracking are effectively off the table.
Cross-Platform (React Native, Flutter)
One codebase covers iOS and Android. Measured against building two native apps, 30–40% savings on screen development is a realistic expectation. The reason it isn't "half" is that platform-specific branching, store submission, and QA still scale with the number of platforms. The limits show up the moment you need a native module. Bring in a specific payment SDK, an industrial scanner, or customized biometric authentication and you end up writing native bridges yourself, which requires expertise on both the cross-platform framework and the underlying platforms.
Native
Native wins on performance and device access. If you need high-end graphics, precise gesture handling, or day-one support for new OS features, there is no substitute. The tradeoff is two sets of maintenance costs. Every new feature has to be implemented, tested, and released twice.
Hybrid (WebView + Native Shell)
When you already have solid web assets and the native features you need are limited to push and camera access, this is a reasonable compromise. Conversely, for a service with frequent screen transitions and dense interactions, the WebView feel drags down satisfaction. And an app that does nothing but wrap an existing website can be rejected during store review on those grounds alone.
Running Costs Outweigh Initial Development
The most common budgeting mistake is counting only the initial build. In practice, these items recur every year:
That last item can reshape the business model itself. If you sell subscriptions through the app, a meaningful portion of revenue goes to the store, so pricing needs to be reviewed alongside the technical design.
The Cost of Getting Requirements Wrong
The most familiar failure runs like this. To save money, the team starts with a WebView-based app. Six months later, offline mode and Bluetooth device integration arrive as requirements. The WebView architecture cannot absorb them, so the app is rebuilt on a cross-platform framework and the initial development cost is effectively paid a second time.
The other common pattern is duplicating admin features between web and app. A request comes in to put part of the admin console into the app, the same logic ends up implemented in two places, and every policy change now requires edits on both sides. Keeping admin functionality on the web and simply opening it in a browser from the app is far cheaper over time.
What both cases share is that they are failures of requirements definition, not technology selection. Simply cataloging the features that might plausibly arrive within the next year prevents most of this.
Recommended Paths by Stage
If you are still validating, build the web version first. Prove the core flow with responsive web, check metrics like return visit rate and core feature usage frequency, and then decide on an app. Starting with an app at this stage slows down hypothesis testing itself, because every iteration waits on store review.
Once you are scaling and push retention and device features are genuinely necessary, cross-platform gives the best cost-to-coverage ratio for supporting both stores at once. If a specific screen falls short on performance, you can replace just that piece with a native module rather than rewriting everything.
Native-first is best reserved for products with heavy hardware dependencies or where raw performance is the competitive advantage.
Working with POLYGLOTSOFT
Through our subscription development service, POLYGLOTSOFT has a single team design and operate both your web and mobile products. Because the same team owns the backend API, the admin web console, and the mobile app, duplicated feature design and version compatibility problems are structurally less likely. Since it is a flat monthly subscription, recurring operational work like annual OS update support, store review handling, and forced update policy management is included rather than quoted separately.
We are happy to start by reviewing whether you need an app at all. Submit a requirements document (PRD) and we will respond within 24 hours with a prototype and a reasoned recommendation on whether web, cross-platform, or native fits your case. Get in touch to start the conversation.