We founded Web Systems in Łódź back in 2006. Mobile apps? Barely walking. AI? Locked away in research labs. Today our clients come to us with something concrete – they want apps that understand context, anticipate user needs and automate work that until now required a human being. This is not an AI fad. It is a response to a market that has changed. E-commerce and B2B companies need intelligent mobile tools built on AI, because their customers simply expect personalized experiences. That is all there is to it. What we share here is the perspective of a contractor who has travelled the road from the first experiments with language models to production rollouts. We will show you the architectural decisions, the mistakes (there were plenty), the costs and the lessons from real projects.
Spis treści
Where the idea of combining a mobile app with AI came from
The impulse did not come from a conference or a Gartner report. It came from conversations with clients. One of them managed hundreds of products in a B2B system and needed a way for his sales reps to find answers to customer questions faster. He put it bluntly – “my people lose an hour a day hunting for specifications in PDFs, do something about it”. So we did. That kind of problem is solved by a well-designed AI module, not by yet another full-text search engine.
The difference between a buzzword and something that actually works? Enormous. Plenty of companies add “AI” to their product description because it sounds modern. But real value only appears when the model solves a specific user problem. In our practice that usually means question-and-answer systems built on a company knowledge base, intelligent product recommendations or automatic content categorization. Each of these scenarios calls for a different technical approach. And a different architecture.
The decision to implement RAG (Retrieval-Augmented Generation) came naturally. A classic LLM generates answers based on its training data – and that means a risk of hallucinations and outdated information. RAG removes that problem, because the model draws its knowledge from a specific, curated base of client documents. But not every project needs a solution that advanced. Simpler cases? We handle them with well-tailored prompt engineering, without any additional semantic search infrastructure.
“The retrieval mechanism in RAG is critically important. You need the best semantic search on top of a curated knowledge base to ensure that the retrieved information is relevant to the input query or context. If your retrieved information is irrelevant, your generation could be grounded but off-topic or incorrect.”
That quote gets to the heart of what we see in our projects. The quality of AI answers depends above all on the quality of the retrieval mechanism and of the knowledge base itself. Investing in data curation pays off many times over. And trying to make up for weak sources with a better language model? That leads nowhere. I have tested it.
Mobile architecture ready for artificial intelligence
Choosing the technology stack for a mobile app with an AI component is one of the first decisions that determines whether the whole project succeeds. At Web Systems we work with native solutions (Kotlin, Swift) and cross-platform ones (Flutter, React Native). For AI integrations we prefer an approach in which the logic of communicating with the models sits on the backend, while the mobile app remains a lightweight presentation client. Why? Because it gives you the flexibility to change the AI model without having to push an app update to the store. And we change models often.
The foundation of a scalable mobile app is the separation of layers. The UI layer is responsible solely for presentation and interaction. The data layer manages API communication, caching and offline synchronization. Between them, optionally, sits a domain layer that encapsulates complex business logic. And what does that split give you? Adding an AI module – a chatbot, a recommendation system, image analysis – does not require rebuilding the existing application. You simply plug in a new element.
“App architecture is the foundation of a high-quality Android application. A well-defined architecture lets you create a scalable, maintainable app that can adapt to the ever-expanding ecosystem of Android devices. (…) The most important principle is separation of concerns: separating your app into methods, classes, files, packages, modules and layers that have clearly defined responsibilities and boundaries.”
Twenty years of software development. I confirm that principle without reservation. Projects in which the client insisted on rapid prototyping at the expense of architecture generated technical debt that later cost many times more than that initial “saving” of time. Especially with AI integration – where requirements shift dynamically with every new model version – solid architecture is not a luxury. It is a condition for the project to survive.
Tip: When designing a mobile architecture for future AI modules, introduce an abstraction layer for communicating with inference services from the very beginning. Define an interface that lets you swap the model provider (OpenAI, Anthropic, local models) without touching the presentation layer. In practice this means building a dedicated data repository for AI responses with a uniform contract, independent of any particular API.
Challenges of integrating AI models with a mobile app
The first question at the start of every project with an AI component is where to run the model. On-device inference (edge) removes network latency and works offline, but it drastically limits the size of the model. You have to optimize for specific mobile chips. The cloud gives you access to the most powerful models, but it generates costs proportional to the number of queries and makes you dependent on connection stability. In most of our projects we choose a hybrid approach. Simple tasks (classification, keyword extraction) run locally. Complex text generation goes to the cloud.
Data security is the topic that worries corporate clients most. And rightly so. Sending user queries to an external language model API means that sensitive information leaves the company’s controlled infrastructure. We use several strategies – anonymizing data before sending it, dedicated model instances with a guarantee that data will not be used for training, end-to-end encryption, and local pre-processing that filters out personal data before it reaches the LLM. We select each solution individually to match the client’s regulatory requirements. There is no single universal approach here.
Handling offline states is another thing specific to mobile platforms. A user in the field (a sales rep, an inspector, a service technician) loses coverage and expects the app to keep working. So what do we do? We design systems for caching AI responses, queueing requests for later processing and intelligently prefetching the information that is needed most often. These mechanisms require careful management of device memory, because models take up a lot of space and older phones have limited resources.
The typical mistakes we learned to avoid during our first integrations? No handling of timeouts on requests to the model API. Ignoring input token limits (which leads to the context being truncated). Not logging the cost per request. And my favourite – testing exclusively on fast office WiFi instead of in real mobile network conditions. We discovered every one of these problems in production. Painful lessons, but effective.
RAG, fine-tuning and prompt engineering in project practice
Choosing the AI technique for a specific business case should follow from an analysis of the data and the needs. Not from fascination with technology. Prompt engineering works when the client has standardized queries and needs predictable answer formats – generating product descriptions, translations, extracting data from forms. Fine-tuning comes into play when the model has to understand specific industry jargon or the company’s tone of communication. RAG, on the other hand, is irreplaceable wherever answers must be based on a current, company-owned knowledge base – technical documentation, terms and conditions, product catalogues.
The RAG Ops approach, meaning metric-driven quality management for a retrieval-augmented generation system, changed the way we run AI projects. Instead of a subjective “the answer looks fine”, we measure specific parameters of every generated response. That lets us systematically optimize the whole pipeline – from parsing the source documents, through the chunking strategy, to the prompt that steers the generation itself. Without metrics, iteration is shooting in the dark. With them, it becomes an engineering process.
The metrics we use to evaluate AI responses in our projects:
- Coherence – logical consistency of the answer, no internal contradictions
- Groundedness – anchoring in sources, the degree to which the answer relies on the documents provided
- Fluency – linguistic smoothness and naturalness of the generated text
- Safety – content safety, no generation of harmful or inappropriate answers
- Instruction following – compliance with the given instructions and answer format
- Question answering quality – how well the answer matches the question that was asked
Curating the knowledge base is the element clients most often underestimate. Chunking strategies – the way documents are split into fragments indexed by the semantic search engine – have a direct impact on answer quality. Fragments that are too large blur retrieval precision. Fragments that are too small lose context. In our projects we experiment with semantic chunking (splitting along logical paragraphs), overlapping chunks and hierarchical chunking (preserving the document structure). The optimal variant? We determine it empirically for each type of documentation. There are no shortcuts here.
Costs, schedule and MVP – what to tell the client straight
Cost transparency in the IT industry tends to be treated selectively. No surprise there. At Web Systems we adopted the principle that the client should know the full financial picture of a project before making a decision. A realistic budget for a mobile app with an AI component starts at 80,000-150,000 PLN for an MVP and grows in proportion to the complexity of the model, the size of the knowledge base and the performance and security requirements. Implementing RAG alone, with a dedicated vector database and an API to serve queries, usually accounts for 30-50% of that budget.
The MVP strategy makes sense because it lets you verify the business value of AI before the client invests in a full version. For the first iteration we pick one, most important AI feature – usually a question-and-answer chatbot on the company knowledge base or intelligent product search. Image analysis, report generation, predictions? We leave those for later iterations, once we know that users really do use the AI component and that it delivers measurable value.
The hidden maintenance costs of an AI project are a topic many contractors keep quiet about. A language model needs regular updates. API providers change versions, deprecate endpoints, revise price lists. The knowledge base needs curation, because the client’s documents change and old chunks go out of date. Monitoring answer quality generates infrastructure costs, and the cost of tokens alone, with a large number of users, can take more than one product owner by surprise. We estimate the annual cost of maintaining an AI system at 15-25% of the initial investment.
Why do we write about this openly? Because a client who understands the cost structure makes better decisions. And does not lose trust in the contractor when, six months in, the API bills arrive or the knowledge base has to be reindexed. Transparency protects both sides from disappointment. It builds a partnership that works over the long haul. I have tested both approaches – I know which one works.
FAQ
How much does it cost to build a mobile app with AI at a Polish software house?
An MVP of a mobile app with an AI component at a Polish software house starts at roughly 80,000-150,000 PLN net. The final figure depends on the complexity of the AI model, the size of the knowledge base, the security requirements and the number of platforms (iOS, Android or both). On top of that come maintenance costs – model updates, monitoring of answer quality and fees for the language model providers’ APIs. That is roughly 15-25% of the initial investment per year. An MVP strategy lets you limit the initial spend and scale the project only after confirming that AI really does deliver business value.
Does AI in a mobile app require a permanent internet connection?
Not always. Hybrid solutions let you run simpler models directly on the device – text classification, keyword extraction or image recognition can all be done offline. Complex generative tasks (chatbot answers, content generation, document analysis via RAG) require communication with a server, because large language models need computing resources that an average smartphone does not have. We design apps with request queueing and response caching, so users can work offline and synchronize the results once connectivity returns.
How long does the rollout of a mobile app MVP with artificial intelligence take?
Realistically? Three to five months, depending on complexity. The first month covers requirements analysis, architecture design and preparation of the knowledge base. The next six to eight weeks are the implementation of the mobile app and its integration with the AI model. The rest goes on testing answer quality, optimizing prompts, performance testing and the rollout itself. Projects with advanced model fine-tuning or complicated security requirements can take longer – we set the detailed schedule after an analytical workshop.
Summary and the next step
Building mobile apps with an AI component requires a combination of mobile engineering skills, distributed systems architecture and practical knowledge of the language model ecosystem. After twenty years in the industry I can see that the success of such projects depends on three things – solid layered architecture, a metric-driven approach to AI quality and honest cost communication with the client. None of these elements is optional.
A partnership with an experienced technical team matters not only during the build stage. Above all, it counts during the maintenance and development of the system. AI models evolve, APIs change, knowledge bases grow – and that is when the quality of the architecture and the maturity of the processes the contractor put in place at the start prove their worth. Cheap prototypes written without separation of layers and without a testing strategy turn into expensive problems after a few months in service. I have seen it many times.
Are you considering building a mobile app with elements of artificial intelligence? Are you looking for a partner to build an MVP, or do you want to integrate RAG with an existing system? Get in touch with us. At Web Systems we combine project experience with practical knowledge of AI – we will gladly talk through your business case, the real costs and a schedule that makes sense.
