Powstania Warszawskiego 15
31-539 Kraków
AI Strategy
A lot of new mobile apps are being built right now, and many get AI features only because everyone else is adding them. When founders ask us about AI features in mobile apps, we start with a simpler question: what should your app do exceptionally well? The rest of this article is that filter in practice.
Here is the pattern we keep seeing. A founder builds a mobile app whose entire value is doing X well: booking equipment, managing field technicians, tracking a habit. Then the pressure kicks in. Investors mention AI, competitors announce AI, LinkedIn is full of AI. And suddenly the roadmap fills up with features that have nothing to do with X.
We have been on the other side of that conversation. A client came to us wanting AI in their mobile app, and when we walked through it together, the honest conclusion was that it generated no business value for their users. It was an investment in a catchphrase. We advised against building it. That is not a comfortable thing for an agency to say, since we would have been the ones paid to build it, but it is the only advice that survives contact with real users.
The most expensive AI mistake in mobile apps is not a bad model. It is a good app stuffed with AI gimmicks that are not life changing for its users.
The filter is always the same: user value first. Users do not open your app wanting AI. They want to type less, wait less, and get to their result faster. If an AI feature does not visibly do one of those things, it is decoration.
When clients ask us whether AI makes sense for their app, the conversation almost always comes down to one distinction that most founders have never had spelled out: the difference between a feature built on top of an existing model through an API and a custom machine learning model trained for your product. These are not two variants of the same thing. They are two completely different investments.
Route A
Existing model through an API
Your app talks to GPT, Claude, or Gemini through your own backend
Effort comparable to any other well scoped mobile feature
You pay for integration, prompt design, and UX, not for teaching a machine
Covers the vast majority of mobile use cases in 2026: summaries, drafts, conversational search, categorization
The model behind the feature can be swapped at any time
Route B
Custom trained ML model
You fund data collection, preparation, training, and evaluation before users see anything
Requires ML specialists on top of your mobile team
Radically different budget, timeline, and risk profile
Justified only when your data is unique and the model itself is the competitive advantage
The exception in mobile products, not the default
Which route is right is not a technology question. It is a question of your budget and your business requirements, and it should be answered in a discovery workshop before anyone writes an estimate. The two costs founders most often underestimate sit exactly at the two ends of this table: the cost of training a custom model on one side, and the running cost of tokens on the other. More on the second one below, because it surprises even the founders who chose the cheaper route.
An existing model through your backend
The sensible default. The app, whether Flutter or React Native, never holds an API key. Requests go through your backend, which streams the response into the UI. Fastest path to value and the easiest to scope and price.
Apple's on device model
Since iOS 26, developers get direct access to the model behind Apple Intelligence, running entirely on the phone: no network requests, no API key, no per request bill, and no user data leaving the device. In React Native it is already reachable in production apps; the practical integration is described below. Honest limits: iOS only, Apple Intelligence capable devices, and a small context window, so it suits focused tasks like summarizing, tagging, and drafting.
Classic on device ML for narrow tasks
ML Kit, Core ML, TFLite: document scanning with the camera, OCR, image recognition, classification. Mature, free to run, works offline. Frequently this is the AI feature the client actually needs. They just do not know it does not require a large language model.
A custom trained model
The path for the few. Reserved for products where the data is unique and the model is the moat, not the interface. Different budget, different timeline, different risk.
In a React Native app, the integration goes through React Native AI and its Apple provider. The library plugs Apple's model into the interface your team already uses for cloud models, so the same calls now run on the phone instead of a server. The app first checks whether the device supports Apple Intelligence; where it does not, the request falls back to your backend and a cloud model, so one codebase quietly serves both worlds.
One reassuring note for founders choosing a framework: whether your app is Flutter or React Native barely matters here. The AI logic lives in your backend or in the on device model layer. The framework's job is the interface.
A regular feature costs money once, when you build it. An API based AI feature also costs money every single time someone uses it, in tokens billed by the model provider. That cost scales with your success: more users, more usage, bigger bill. It never goes away.
This changes how a feature should be designed from day one. Capping context sizes, caching repeated queries, routing simple tasks to smaller and cheaper models, and setting sensible per user limits are architecture decisions, not optimizations for later. It is also part of why the on device options above deserve a serious look for high frequency features: their marginal cost per use is zero.
Paid to us. Once.
The build
Designing and building the feature. One number, agreed after the discovery workshop, and it does not move.
Paid to your model provider. Monthly.
The tokens
Billed directly to your own account with OpenAI, Anthropic, or Google. The money never passes through us, so nothing hides on top of it and the real running cost is visible to you from the first request.
We think this is the only honest way to structure it, and we recommend founders demand this split from any development partner. It is one of the reasons AI features fit fixed price contracts better than most people expect: a narrow, well defined feature on the API route is a scopeable piece of work like any other. What breaks budgets is not AI. It is open ended requirements to make the app smart. For how these decisions fit into an overall budget, see our guide to mobile app development cost.
Nobody can name the metric it should move
If the question "what number changes if this works" gets silence, it is a demo, not a feature.
It replaces a flow that already works in two taps
AI that adds a conversation where a button existed makes the app slower. Nobody wants to chat with their invoice app.
It needs data you do not have yet
Personalization for an app with no users is built on assumptions, not behavior. Ship first, learn, then personalize.
It exists because of hype, not because of your users
Investor pressure and competitor announcements produce features that get shipped once and opened never. We have advised clients to cut exactly these.
Nobody has decided what happens when the model is wrong
Every model sometimes is. A draft the user edits before sending is a different situation than an automatic categorization running in the background. This is a per feature design decision, and it belongs in the discovery workshop, not in a bug report after launch.
Our rule is the same one we apply to every MVP: if the core value of the product is impossible without AI, then AI is the product and belongs in the MVP. If AI is an enhancement to a product that should do X well, ship the MVP doing X well, collect real usage data, and add AI where the data shows friction.
Either way, the decision deserves the same treatment as every other scope decision: it gets made in a structured discovery process, against your users' journey, before anyone writes an estimate.
Is a "ChatGPT wrapper" a bad architecture?
No, and the framing is backwards. Building on a proven model through an API is the correct architecture for the vast majority of mobile use cases in 2026. You can swap the model at any time. You cannot recover a budget spent training a custom model for a feature users did not want.
Who pays for the tokens?
In a well structured contract: you do, directly to the model provider, on your own account, with full visibility. If a development partner wants to bundle token costs invisibly into their price, ask why.
Can AI features run without internet?
Increasingly, yes. Apple's on device model and classic on device ML handle focused tasks with zero network and zero per use cost. For anything heavier, the app needs a designed offline behavior, which is a UX decision, not an afterthought.
Does Flutter or React Native limit our AI options?
No. Both frameworks integrate with API based models through your backend, and both have paths to on device AI. The framework handles the interface. The AI lives underneath it.
The most common in 2026: document scanning and OCR with the camera, summarizing content inside the app, drafting messages the user edits, conversational search across the app's own content, automatic categorization, and personalized recommendations once the app has real usage data.
An API based feature builds on an existing model such as GPT, Claude, or Gemini, so the effort is comparable to a regular well scoped feature. A custom model means funding data collection, preparation, training, and evaluation, plus the specialists to do it, before users see anything. They are two completely different investments, and choosing between them is the first budget decision of any AI feature.
API based features do add a recurring cost: tokens billed by the model provider every time the feature is used, scaling with your user base. On device approaches remove the per use cost but constrain what the feature can do. Good architecture, such as caching, context limits, and routing simple tasks to smaller models, keeps the bill under control.
Not for API based features. An experienced mobile team with backend competence covers integration, prompt design, and the UX around the model. Custom model work is a different scope that does require ML specialists.
Only if the product's core value is impossible without it. Otherwise ship the MVP focused on its core job, collect real usage data, and add AI where the data shows friction users actually feel.
Neither has a meaningful advantage. The AI layer is framework agnostic: API based models sit behind your backend, and both ecosystems have paths to on device AI. Choose the framework based on your product and team, not on AI plans.
Not sure if AI belongs in your app?
We will give you our honest take on what your idea needs and what to build first.
Book an intro call