Mobile product development: a roadmap from discovery to scale, with on-device and cloud AI

This guide is for founders, product owners and CTOs who are planning a new mobile app or rebuilding one that has stalled. It sets out a roadmap from discovery to scale, the native versus cross-platform decision, backend and API design for mobile, where AI features should run, security, app store release operations, and how timelines and teams are usually shaped. It closes with trade-offs, common mistakes and a launch checklist.

In this guide

• The roadmap at a glance
• Discovery: decisions to make before design
• Native or cross-platform: the decision
• Backend and APIs built for mobile
• AI features: on the device or in the cloud
• Security from the first sprint
• Release operations and the app stores
• Timelines, team and delivery rhythm
• Proof from commerce and what it shows
• Trade-offs and common mistakes
• A mobile launch checklist
• Planned guides in this cluster
• Limitations of this guide
• Frequently asked questions
• How this guide was made
• Next step

The roadmap at a glance

A mobile product rarely fails because the first screens were hard to build. It fails because the wrong job was chosen, the backend could not keep up, or releases turned into emergencies. A staged roadmap puts a decision and an exit test at each step.

Each stage can stop without leaving half-built work behind. That matters because mobile products often learn in stage 2 or 3 that the job, the audience or the price must change.

Discovery: decisions to make before design

Discovery is where most of a mobile product's cost is decided. Settle these questions before design starts:

• User and job. Who uses the app, in what situation, and what one job must it do better than the alternatives, including a website?
• App or mobile web. If the job needs no device features, no offline use and no home-screen presence, a responsive web experience may be enough and cheaper to run.
• Platforms. iOS, Android or both at launch, phones only or tablets too, and which minimum operating system versions to support.
• Offline and poor networks. What must work without a connection, and what happens to actions taken offline.
• Device features. Camera, location, biometrics, push notifications, payments, Bluetooth or health data each add design, permission and review work.
• Integrations. Which systems the app reads from and writes to: accounts, orders, payments, CRM, ERP or a content system.
• Store and business rules. How the app earns money, because store rules on in-app purchases and subscriptions shape the product design.
• AI features. Which jobs AI makes faster, such as search, camera recognition, an assistant or personalised content, what data each needs, and whether it must work offline.
• Data and privacy. Which personal data is collected, why, where it is stored, and how consent is recorded.
• Success measures. Activation, retention, conversion or task completion, defined as analytics events before the first line of code.

The output of discovery is a first release small enough to build in weeks, and a list of what is deliberately left out.

Native or cross-platform: the decision

There are three broad ways to build a mobile product, and each is the right answer for some products.

Six questions settle most decisions:

1. How deeply does the product use device features? The deeper, the stronger the case for native.
2. Must iOS and Android launch together? If yes, cross-platform usually reaches parity sooner.
3. How demanding is the interface? Complex animation, real-time graphics or camera processing favour native.
4. What skills will maintain it? A product is maintained for years; choose what your team or partner can support.
5. How much can be shared with other channels? A web team may reuse logic, design systems and APIs.
6. What does the next stage need? Decide for the product you expect in stage 5, not only for stage 2.

A mixed approach is common and healthy: a cross-platform app with native modules for the few features that need them.

Backend and APIs built for mobile

The backend is where mobile products differ most from websites. A website can be updated for every user at once; a mobile app cannot, because users update when they choose.

• Old versions live on. Version your APIs and keep them backward compatible for as long as supported app versions are in use. Set a minimum supported version and a way to ask or require users to update.
• Design for poor networks. Keep the number of round trips low, paginate lists, send images sized for the device, and make requests safe to repeat so a retry after a timeout does not create a second order.
• Offline use needs a sync model. Store what is needed locally, queue changes made offline, and decide how conflicts are resolved when the device reconnects.
• Authentication for devices. Use short-lived access tokens with refresh, protect tokens in the platform's secure storage, and offer biometric sign-in where it helps.
• Notifications with consent. Push messages go through the platform notification services; ask for permission at a moment the user understands, and let them control categories.
• Remote configuration and feature flags. Switch features on and off, or change content, without waiting for a store release.
• Observability from day one. Crash reporting, performance traces and the analytics events defined in discovery should ship in the first release, not after launch.

Where the same backend serves a website, a mobile app and partners, treat the API as a product of its own, with documentation, versioning rules and monitoring.

AI features: on the device or in the cloud

Users now expect apps to recognise what the camera sees, answer questions in plain language and put the right content first. Where each AI feature runs is an architecture decision with consequences for privacy, cost, speed and release cadence, so make it per feature.

As a rule of thumb, on-device suits text recognition from the camera, image classification, simple ranking and features that must work offline. The cloud suits assistants, search that understands intent across a large catalog, document understanding and anything that reads your business data. Many products combine both: a quick on-device first pass, with harder cases sent to the cloud.

Design rules for cloud AI in a mobile app:

• Call AI through your own backend. Never ship an AI provider key in the app package; the backend holds keys, applies per-user limits and can switch model or provider without an app update.
• Plan a fallback. When the AI service is slow or unavailable, the core job still works.
• Keep people in charge of consequences. An assistant can draft an order change or a support reply; the user or a staff member confirms it.
• Disclose it. Store privacy disclosures and in-app notices should say what AI processes and where.

Security from the first sprint

The OWASP Mobile Application Security Verification Standard (MASVS) organizes mobile security requirements into eight control groups: storage, cryptography, authentication and authorization, network communication, platform interaction, code quality, resilience against tampering and reverse engineering, and privacy. Buyers can use these groups to state requirements in the first backlog and to ask a partner how each one is tested, rather than commissioning a security review at the end.

Practical starting points are: keep secrets, including AI provider keys, out of the app package, store sensitive data only in the platform's protected storage, use TLS for every connection, check authorization on the server rather than trusting the app, collect only the personal data the job needs, and scan dependencies on every build.

Netbase's published security practices include secure code review and version control, TLS in transit and AES at rest, role-based access control, MFA for admin dashboards, vulnerability scanning and penetration testing, and disaster recovery; NDAs, DPAs and SLAs are available on request, and contributors work under NDA. These are practices, not a guarantee about any particular app.

Release operations and the app stores

Launching a mobile product means passing review by two store owners whose rules change over time, and then releasing again and again without disrupting users.

• Apple. The App Store Review Guidelines are organized in five sections: safety, performance, business, design and legal. The business section covers payments, including in-app purchase and subscriptions, and the legal section covers privacy and data handling. Read them during discovery, not the week before submission.
• Google Play. Google requires new apps and app updates to target a recent Android API level, and existing apps that fall below a minimum target level become unavailable to new users on newer devices. Plan a yearly update to keep up with these requirements, even for an app that is otherwise stable.

Good release operations then look like this:

• a beta channel for internal and pilot users before each public release;
• staged rollouts that start with a small share of users and pause on rising crash rates;
• release notes, store screenshots and privacy disclosures kept current;
• a hotfix path, with server-side switches to disable a broken feature while a fix is reviewed;
• a regular update rhythm for operating system changes, dependency updates and security fixes;
• server-side flags for AI model or prompt changes, checked on a small share of users before full rollout.

Timelines, team and delivery rhythm

Netbase does not publish a separate range for mobile apps. Its typical ranges for SaaS products are 8 to 12 weeks for an MVP, 3 to 6 months for a mid-tier product and 6 to 12 months or more for an enterprise product. These are typical ranges that depend on scope, not quotes; a mobile product with its own backend, integrations and both platforms sits higher in a range than a single-platform app on an existing API.

What moves a mobile timeline:

• the number of platforms and devices supported at launch;
• device features that need native work or extra store review;
• integrations with existing systems and the state of their APIs;
• offline requirements and the complexity of sync;
• how quickly product decisions and content are ready.

Netbase teams range from 3 to 30 people, combining business analysts, project managers, solution architects, developers, QA and UI/UX designers, and work typically starts within 1 to 2 weeks after discovery. Delivery follows a six-step lifecycle from discovery and architecture planning through agile execution with outcome-based milestones to rollout and ongoing support. Sprints end in weekly reviews on test builds, the team works remote-first from Hanoi in English, and the backend is designed API-first so the app, the website, partner systems and AI services share the same interfaces.

For a team that plans and builds mobile products through these stages, see Netbase's mobile app development service. Where a reusable starting point fits the product, the mobile product accelerator describes how Netbase approaches a shorter path to the first release.

Proof from commerce and what it shows

RB Marketplace and Dey Page. Netbase built two apps that follow the pattern in this guide: one backend and API serving both a web platform and a mobile app. The RB Marketplace customer shopping app runs on the marketplace's API with Firebase push notifications for orders and deals (RB Marketplace case study). The Dey Page React Native app for iOS and Android shares listings, users and payments with its web directory in Nigeria (Dey Page record). Neither record publishes usage figures.

USticker. For USticker, Netbase delivered an e-commerce payment enhancement engagement. The published results are conversion up 40% for users of the design tool, completed designs up 32% in six months, retention up 25%, online-order revenue up 15% and page load time down 21%. The figures describe the engagement as a whole, as reported for that client, and the 40% applies only to users of the design tool. This is a commerce case, not a native app case study; it is included because the measures it moved (conversion, completion, retention and speed) are the ones a mobile commerce product should track from its first release.

Read the USticker case

Recognition. Among Netbase's recognition badges is Top Mobile App Developers 2020, Clutch.

Commerce is where mobile products meet the hardest mix of payments, catalogs, orders and customer accounts. Read how Netbase approaches storefronts, marketplaces and order operations in retail and e-commerce.

Trade-offs and common mistakes

• Building an app when mobile web would do. An app adds store review, updates and two platforms. Build one when the job needs it.
• Choosing the framework before the product. Decide on device features, platforms and team first; the framework follows.
• Treating the API as an afterthought. A backend designed for a website breaks under old app versions, poor networks and offline use.
• Launching everything at once. A wide first release hides which feature users value and multiplies review risk.
• No analytics or crash reporting at launch. Without them, the growth stage runs on opinion.
• An AI key inside the app. Anything shipped in the package can be extracted; route AI calls through your backend.
• Forgetting the yearly platform update. Store and operating system requirements change even when your product does not.

A mobile launch checklist

• The user, the job and the success measures are written down and agreed.
• The app, mobile web or both decision is made and justified.
• Platforms, devices and minimum operating system versions are chosen.
• Native, cross-platform or mixed is decided against device features, parity needs and team skills.
• APIs are versioned, safe to retry and documented; a minimum app version policy exists.
• Offline behaviour and sync conflicts are specified where needed.
• Security requirements are mapped to the OWASP MASVS control groups.
• Store guidelines, payments rules and privacy disclosures have been reviewed.
• Crash reporting, performance traces and analytics events ship in the first release.
• A beta channel, staged rollout and hotfix path are in place.
• A yearly platform update is planned in the roadmap.
• Each AI feature is assigned to the device or the cloud, with provider keys on the server and a fallback when AI is unavailable.

Planned guides in this cluster

This pillar anchors deeper guides now being planned: a step-by-step mobile app development roadmap from discovery to scale; native versus cross-platform mobile development; mobile backend, API and offline architecture; and mobile app maintenance, security and release operations. Until they are published, the sections above cover the essentials.

Limitations of this guide

This is practical guidance from Netbase delivery experience, not original research. Store rules from Apple and Google, and the OWASP MASVS, were checked on the access date and change over time, as do on-device AI capabilities; read the current versions before you plan a release. Netbase's timeline ranges are published for SaaS products, are typical and depend on scope, and no separate mobile range is published. The USticker results were reported for that engagement as a whole and depend on the client's baseline and market; no app store download or rating figures are claimed.

How this guide was made

The Netbase Editorial Team wrote this guide from Netbase's published delivery, timeline and security pages, the USticker case study and public guidance from OWASP, Apple and Google. David (CEO) reviewed every Netbase fact. External sources are cited with access dates. Drafting used AI assistance (Claude). Its purpose is to help product owners plan a mobile product that keeps working after launch.

Next step

Share the job your mobile product must do, the platforms you need and the systems it must connect to, and we will book a solution review to shape the first release and the roadmap after it. You can also see the related service or browse more Netbase insights.

Related services and solutions