Building a mobile app: native, cross-platform or web
Before commissioning a mobile app, three decisions come first: do you really need an app, which approach will it be built with, and who maintains it after launch. The process, store review and the items that grow cost.
Building a mobile app means developing software that is installed on a phone and distributed through the App Store and Google Play; but most of the work is not on the screens, it is in the server the app talks to and in maintenance after launch. Before asking for quotes, three decisions come first: do you really need an app, which approach will it be built with, and who will maintain it after launch.
Do you really need a mobile app?
Downloading an app is a much bigger step for a user than visiting a website. An app pays for itself when there is:
- Frequent use. Customers or staff open it several times a week.
- A need for phone capabilities. Camera, location, notifications, offline use, Bluetooth.
- Loyalty and repeat sales. Logged-in users brought back with notifications.
If users drop by a few times a year or only look up information, a web application that works well on a phone is often enough, at a fraction of the cost. The difference is covered in what is web software.
Native, cross-platform or web?
| Approach | What it means | When |
|---|---|---|
| Native | Written separately for iOS and Android | When top performance and deep device access are needed |
| Cross-platform | Two platforms from one codebase (React Native, Flutter) | For most business and customer apps |
| Web app (PWA) | Runs in the browser, can be added to the home screen | For internal tools that need no store and update often |
Cross-platform is a sensible default for most projects today: one team, one codebase, two stores. Native should be kept for special cases such as games, heavy animation or deep integration with device hardware.
The invisible half of a mobile app: the back end
Every list, login and notification in the app comes from a server. So check whether a quote includes:
- API and database. The server side the app talks to. If you already have a website or panel, the same back end can be shared.
- Admin panel. Where you manage content, users and orders.
- Notification infrastructure. Which notification goes to whom, and when.
- Analytics. Which screens are used, and where users drop off?
A quote that prices only the screens has priced half the job.
How does the process run?
- Discovery. Users, main flows, device features needed, integrations. The output is a written scope; how to prepare one is in the software requirements brief.
- Screen design. The main flow first: sign-up, login and the app’s core job.
- Development. In two-week cycles, each ending with a test build you can install on your own phone.
- Store preparation. Screenshots, descriptions, privacy disclosures, test accounts.
- Store review. Apple and Google review the app; if rejected, it is fixed and resubmitted. Leave room for this in the timeline.
- Launch and monitoring. Crash reports, usage data, first updates.
Items that grow cost and timeline
- User roles. Customer, courier, manager: each role is almost a separate app.
- Payments and subscriptions. In-app purchase rules and commissions need planning of their own.
- Offline use. Data sync is one of the hardest parts of any app.
- Integrations. Accounting, ERP, CRM, shipping. Each one is its own uncertainty.
- Operating system updates. iOS and Android change every year, and the app has to keep up.
A fixed price for an app without a clear scope either carries a large risk margin or is a number that will turn into an argument mid-project. Why is covered in why software projects go over budget.
What happens after launch?
A mobile app is not finished when it ships. Yearly operating system releases, changing store rules, security updates and user feedback all need an ongoing maintenance budget. When getting quotes, also ask about the scope of post-launch maintenance and who will do it.
Frequently asked questions
Do I need two separate apps for iOS and Android? With a cross-platform approach, one codebase ships to both stores. With native, two separate apps are written.
How long does it take to build a mobile app? It depends on scope; the number of user roles, integrations and payment flows decides it. The exact timeline is given in writing after discovery.
Who owns the app’s source code? You should, and the store accounts should be opened in your name. The contract should say so explicitly.
Can my existing website’s back end be used by the app? Often, yes. If the site’s back end offers an API, or is made to, the app uses the same data.
Boygantech builds web, mobile and AI projects in the same team, so an app’s back end and its web side are not split between separate vendors. To talk about your project, have a look at our software development service.
