When a Business Actually Needs a Mobile App

A mobile app is not a maturity badge. It is a product with store fees, OS permission prompts, update cadence, and a backend that must survive a flaky radio. Palmate Solutions builds mobile apps when a job needs the device. We recommend not building one when a website or a tightened internal console would do the same work with less tax.

This article is the decision, not the build plan. For sequencing once you have decided, read how to plan a mobile app before development.

The jobs that actually need an app

Start with a sentence a field supervisor would recognise. If you cannot write one, you do not have an app brief. You have a desire for an icon.

Apps earn their keep when the job needs at least one of:

• Camera or scanner as a first-class action — damaged cartons, KYC photos, barcode picks.
• Offline queues — orders, picks, or inspections that must succeed in a basement, a mandi, or a truck. See offline-first mobile apps for the sync architecture required.
• Push that is operational — “van is loaded,” not a marketing blast you could send by email.
• Device hardware — Bluetooth printers, GPS breadcrumbs, NFC, a specific OEM’s scanner.
• A companion to an existing product that people open several times a day, not once a quarter.

If the job is “read our brochure on a phone,” that is a website. If the job is “managers look at yesterday’s numbers,” that is closer to an internal dashboard.

Device hardware and capability matrix

Before committing engineering budget to native mobile code, map the exact device APIs your product demands against what modern browsers can deliver:

If your operational workflow relies on background location tracking for delivery couriers or continuous Bluetooth syncing with warehouse scales, a native or cross-platform mobile app is mandatory. If you only need to show catalogue items and let users submit orders, mobile web or a PWA avoids thousands of dollars in store tax.

When a website is the honest product

A well-built responsive site is cheaper to ship, cheaper to update, and does not require Apple or Google to approve a hotfix. Use the web when:

• Content and enquiry forms are the product.
• Users already have an account in a browser and the mobile job is the same job, smaller.
• You do not control the devices and cannot demand an install.
• The first release is a test of demand, not a warehouse workflow.

A Progressive Web App can add home-screen install and limited offline. It is still a website with extra constraints. Do not promise “app-like” if you have not listed which APIs you actually need. Store listing prestige is not a feature.

Use the website cost estimator when the work is still brochure-versus-portal. Use the API project estimator when the real question is whether your backend can support a client at all.

The app store platform tax and lifecycle overhead

Many businesses budget for app design and development while completely forgetting the recurring overhead of maintaining store compliance:

1. Annual Developer Licenses: Apple Developer Program ($99/year) and Google Play Console ($25 one-time) require verified organization D-U-N-S numbers, corporate credit cards, and periodic identity verification.
2. Mandatory OS Updates: Both Apple and Google enforce target SDK upgrades every autumn. If your app does not target the newest Android API level or iOS SDK within 12 months, your app is removed from search or hidden from new downloads.
3. App Review Rejections: Apple App Review frequently rejects apps with vague guidelines ("Guideline 4.2 - Minimum Functionality" if your app is basically a web wrapper). Every update risks review delays during critical marketing launches.
4. Privacy Manifests and Nutrition Labels: Every third-party analytics SDK, error reporter, or advertising tracker must be meticulously declared in your app privacy manifests.

Internal users are a different product

Staff apps look cheap because “we already have the data.” They are often more expensive than customer apps because:

• Shared logins on warehouse tablets destroy audit trails unless you design around them.
• Offline conflict rules for stock are not last-write-wins.
• MDM, kiosk mode, and OS versions of a device fleet become the release plan.

If the audience is five managers on Wi-Fi, an authenticated web console is usually faster to operate. If the audience is sixty pickers with patchy 4G, an app with a queue may be the only honest v1.

Cost that does not show up in the mockups

Budget for store accounts, privacy questionnaires, crash reporting, push certificates, and a person who can ship a hotfix. Two platforms is not “1.4× one platform.” It is two review queues and two permission models even if you share a codebase.

Stack choice comes after the job. Flutter versus React Native versus native is a fit question. Picking Flutter because a freelancer already knows it, then discovering you needed a background location API the plugin cannot reach, is how you pay twice.

A decision you can write down

You need an app when you can tick all of these:

1. A named job that a website cannot do without pain.
2. A v1 that cuts features, not a programme disguised as a sprint.
3. An API contract or a funded API workstream.
4. A named owner for store listings and privacy copy.
5. Devices and network conditions you have actually observed.

If item 1 fails, commission a site. If item 3 fails, you are not ready for UI. Palmate’s mobile discovery exists to make that call early — including the recommendation to stop.

An icon on a home screen is not a strategy. A job that only works on a phone is.

Authoritative References & Standards

To cross-reference the engineering patterns and regulatory considerations described in this guide, consult the following authoritative industry documentation and RFC standards:

• Android Architecture Guides — Official recommendations for building robust, production-quality Android applications.
• Apple Human Interface Guidelines — Design and performance standards for iOS mobile experiences.
• Flutter Documentation on State & Offline Storage — Architectural patterns for resilient cross-platform mobile runtimes.