Not every business needs an app in the app store. Some need a fast web app, some need a conversational assistant, and some need all three. A decision framework with costs, trade-offs and real-world scenarios.
“We need an app” is one of the most common requests a technology partner hears. Sometimes it is exactly right. Often the real need is different: customers want to book faster, staff want to look something up on the go, or the business wants a direct channel to its best customers.
In 2026 there are three serious ways to meet those needs on a phone:
- A native mobile app downloaded from the Apple App Store or Google Play.
- A progressive web app (PWA), a website that installs to the home screen and behaves like an app.
- An AI assistant, a conversational interface on your website, in messaging apps or inside ChatGPT-style tools, that lets people ask for what they need in plain language.
This guide explains what each one is good at, what it costs to build and run, and a decision framework you can use before you commit budget.
Key takeaways
- Choose based on the job your users need done and how often they will do it, not on what competitors have.
- Native apps win for frequent use, deep device features, offline work and rich notifications.
- Progressive web apps win for reach, speed to market, lower cost and discoverability through search.
- AI assistants win when users have varied questions or tasks that are faster to ask than to navigate.
- Many businesses do best with a strong web app first, an assistant for support and discovery, and a native app only when usage justifies it.
The three options in plain language
Native mobile app
A native app is installed from an app store and runs directly on the phone’s operating system. It can be built separately for iOS and Android, or with a cross-platform framework such as React Native or Flutter that shares most code between the two.
Strengths: the smoothest performance, full access to device features (camera, Bluetooth, background location, biometrics, health data), reliable push notifications, offline capability and a permanent icon on the home screen.
Trade-offs: app store review and policies, updates that users must install, separate releases for two platforms, commissions on some digital purchases, and the challenge of persuading people to download yet another app.
Progressive web app (PWA)
A PWA is a website built with modern web technology so it can be installed to the home screen, work offline for key features and send notifications. Since iOS 16.4 in 2023, iPhones have supported web push notifications for web apps added to the home screen, which closed one of the biggest historical gaps.
Strengths: one codebase for every device, instant updates, no app store gatekeeping, found through search and links, and typically lower build and maintenance costs.
Trade-offs: more limited access to some device features, especially on iOS; installation is less familiar to many users; and there is no app store listing to be discovered in.
AI assistant
An AI assistant is a conversational interface, powered by a large language model connected to your data and systems, that answers questions and completes tasks through natural language. It can live on your website, inside your app, in messaging channels, or be exposed to external AI assistants.
Strengths: handles varied questions without users needing to learn your navigation, available around the clock, can complete tasks such as booking or order lookup, and improves as your content improves.
Trade-offs: needs careful design to avoid wrong answers, requires good source content and integrations, has ongoing usage costs, and must be governed for privacy and accuracy.
Side-by-side comparison
| Factor | Native app | Progressive web app | AI assistant |
|---|---|---|---|
| Best for | Frequent, feature-rich use | Broad reach, transactional flows | Varied questions and tasks |
| Device features | Full | Good and improving; some iOS limits | Depends on the channel it lives in |
| Offline | Strong | Possible for key features | Generally needs a connection |
| Discovery | App stores, marketing | Search engines, links, social | Your site, messaging, AI platforms |
| Updates | Users install releases; store review | Instant | Instant; content and prompts updated centrally |
| Relative build cost | Highest | Moderate | Low to moderate, depending on integrations |
| Ongoing cost | Two platforms, OS updates, store compliance | One codebase | Model usage, monitoring, content upkeep |
| Time to first version | Longer | Shorter | Often shortest for a focused use case |
A decision framework: five questions
1. How often will people use it?
If your customers or staff will open it several times a week, a native app’s convenience and notifications can justify the cost. If use is occasional, a web experience reached through search, links or an email is usually better. People rarely download apps for things they do once a month.
2. Which device capabilities do you truly need?
List them honestly. Background location tracking, Bluetooth devices, advanced camera processing, health data or heavy offline use point towards native. Taking photos, scanning a code, getting notifications and basic offline access are often achievable in a PWA.
3. How varied are the tasks?
If users do the same three things every time (check a balance, book an appointment, reorder a product), a well-designed app or web app is fastest. If users arrive with many different questions (“Can I change my delivery address?”, “Which plan includes French support?”, “What documents do I need?”), an AI assistant can be faster than any menu.
4. How will people find it?
New customers mostly discover businesses through search, AI assistants, social media and referrals, which all lead to web pages. A PWA or web experience captures that traffic directly. A native app mostly serves people who already know you.
5. What can you afford to maintain?
The build is the beginning. Native apps need regular updates for new operating system versions and store policy changes. Assistants need content upkeep and monitoring. Budget for at least the first two years of ownership, not just version one.
Common scenarios
| Business | Typical need | Recommended starting point |
|---|---|---|
| Professional services firm | Clients upload documents, check status, book meetings | Secure client portal as a PWA, plus an AI assistant for FAQs |
| Retail or e-commerce brand | Browsing, buying, reordering, loyalty | Fast mobile web store first; native app once repeat-purchase frequency is proven |
| Field service company | Technicians need jobs, maps, photos, offline forms | Native or cross-platform app for staff; web booking for customers |
| Association or membership organisation | Events, directory, member resources, renewals | PWA member portal with notifications; assistant to answer member questions |
| School or training provider | Schedules, announcements, parent communication | PWA or platform app; assistant for common parent and student questions |
| Fintech start-up | Account management, payments, identity verification | Native app for core customer experience, with strong security; web for onboarding and marketing |
| SaaS company | Product access on mobile | Responsive web app first; native companion app if mobile usage is significant |
The hybrid path most businesses should consider
For many growing businesses, the strongest sequence is:
- A fast, responsive web app or PWA that handles the core journeys and is found through search.
- An AI assistant connected to your knowledge base and key systems, handling questions and simple tasks on the web and in messaging.
- A native app later, built on the same back-end services, once usage data shows a group of frequent users who would benefit.
Designing a clean back end with well-defined APIs from the start makes this path much cheaper, because each new front end reuses the same services.
Getting the AI assistant right
Because assistants are newer, they are the option most often done poorly. Five design rules:
- Ground it in your content. Connect the assistant to approved sources: your website, policies, product data and help articles. Show links to sources in answers.
- Give it a narrow job first. “Answer questions about our services and book consultations” beats “answer anything”.
- Connect it to real actions carefully. Order lookup, booking and lead capture create real value; anything involving payments or account changes needs authentication and confirmation.
- Hand off gracefully. Make it easy to reach a person, and pass the conversation context so the customer does not repeat themselves.
- Monitor and improve. Review conversations, track unanswered questions and fix the content gaps they reveal.
Cost drivers to plan for
| Cost driver | Native app | PWA | AI assistant |
|---|---|---|---|
| Design | Platform-specific patterns for iOS and Android | Responsive design across screen sizes | Conversation design, tone, escalation flows |
| Development | Two platforms or a cross-platform framework | One web codebase | Integrations, retrieval setup, guardrails |
| Back end | APIs, authentication, data | Same | Same, plus content indexing |
| Launch | Store accounts, review, listings | Hosting, domain, installation prompts | Channel setup, testing with real questions |
| Ongoing | OS updates, store compliance, crash monitoring | Hosting, updates | Model usage, monitoring, content updates |
A six-week discovery process before you build
The most expensive app is the one built on assumptions. A short discovery phase usually saves far more than it costs.
| Week | Activity | Output |
|---|---|---|
| 1 | Stakeholder workshop: goals, users, constraints, budget | Problem statement and success metrics |
| 2 | Interviews with 8 to 12 real users or customers | Top jobs to be done, pain points, frequency of use |
| 3 | Review of analytics, support tickets and search data | Evidence of what people actually look for and struggle with |
| 4 | Option analysis: native, PWA, assistant or hybrid | Recommendation with cost and timeline ranges |
| 5 | Clickable prototype of the core journey | Something users can try before code is written |
| 6 | Prototype testing and technical architecture | Validated scope, architecture plan and fixed-price proposal |
By the end of discovery you should be able to answer five questions in writing: who the product is for, which two or three jobs it must do brilliantly, how often people will use it, how success will be measured, and what the first version will not include.
Mistakes we see most often
- Copying a competitor’s app without knowing whether their customers use it.
- Starting with features instead of journeys. A list of 40 features is not a product; three journeys done well usually are.
- Ignoring the back office. An app that takes bookings but forces staff to re-enter them elsewhere creates new work.
- Underestimating content. Assistants and apps both need accurate, current content. Someone must own it.
- No plan for adoption. Even a great app needs a launch plan: in-store prompts, email campaigns, onboarding and reasons to come back.
- Skipping accessibility. Screen reader support, sufficient contrast and scalable text are not optional extras; they also make products easier for everyone.
Frequently asked questions
For many businesses, yes, especially for occasional use, transactional flows and content. For frequent use, heavy device features or demanding offline needs, native still has the edge.
Yes. If the back end and APIs are designed well, a native app can reuse them, so the earlier investment is not wasted.
It can if it is poorly designed. Grounding answers in approved content, limiting scope, showing sources, testing with real questions and offering a human handoff greatly reduce the risk.
Not necessarily. Cross-platform frameworks such as React Native and Flutter let one team build for both with a largely shared codebase, which suits most business apps.
Define it before you build: bookings completed, support tickets deflected, repeat purchases, time saved for staff, or active users per week, and track it from launch.
The bottom line
The right question is not “Do we need an app?” It is “What job do our users need done, how often, and through which door will they arrive?” Answer that honestly and the choice between native, web and AI usually becomes clear, and you avoid paying for an app nobody opens.
Netxeno designs and builds mobile apps, progressive web apps and AI assistants on shared, scalable back ends. Tell us what your users need to do, and we will recommend the leanest way to get there. Start with a free consultation.
